linux-kernel - Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 Apr 2008 16:17:25 +0200
From:	Tomasz Chmielewski <mangoo@...g.org>
To:	Artem Bityutskiy <dedekind@...dex.ru>
Cc:	LKML <linux-kernel@...r.kernel.org>, penberg@...helsinki.fi,
	Jörn Engel <joern@...fs.org>,
	ext-adrian.hunter@...ia.com, jwboyer@...il.com, w@....eu,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

Artem Bityutskiy schrieb:
> Tomasz Chmielewski wrote:

(...)

>> Performance is only one factor in the equation. Other factors are: 
>> cost and reliability.
>>
>> I speak from experience: flash-based block devices tend to have poor 
>> wear-levelling (at least Transcend IDE-flash disks).
>> To reproduce:
>> - format a 2 GB Transcend IDE-flash disk with ext3
>> - write a small file (50-100 kB)
>> - update that file ~several hundred thousand times - as you finish, 
>> IDE-flash disk will have 200-300 badblocks
> Yeah, that's bad. But if you have a bad FTL, surely there is not guarantee
> a flash FS will help? Isn't it better to use better hardware?
> 
> We did some experiments with MMC cards and we were unable to wear them
> out with re-writing the same sectors again and again. This suggests there
> _is_ better FTL hardware then that USB stick you was using.
> 
> Anyway, your original mail said Logfs can work with block devices. My 
> answer -
> UBIFS too, but this is very strange to do this IMO. But OK, it might is not
> senseless, sorry for the wording. :-)

I was thinking why my IDE-flash disk died so soon[1] and how efficient 
can an internal wear-levelling be in devices which hide its "flashiness" 
(USB-sticks, IDE-flash disks etc.).

Internal wear-levelling mechanism doesn't have a clue about free space 
on the filesystem - it that case, how can it do any efficient 
wear-levelling?



[1] Well, it didn't die, really. Once I removed the file which was 
showing I/O errors and did "dd if=/dev/zero of=bigfile", there are no 
badblocks anymore - probably remapped.



-- 
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/