linux-kernel - Re: ext2 on flash memory

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:	Thu, 14 Jun 2007 20:22:02 +0200
From:	Jörn Engel <joern@...fs.org>
To:	Jörn Engel <joern@...fs.org>
Cc:	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: ext2 on flash memory

On Thu, 14 June 2007 19:45:10 +0200, Jörn Engel wrote:
> 
> Nearly two years ago I have spoken to a person that reverse engineered
> the behaviour of several chips used in pendrives.  At the time that
> reverse engineering apparently covered most of the market.  The details
> were quite lengthy but can be condensed to two words: Smartmedia format.

Maybe I should add that things have allegedly improved.  Many devices
today support both static and dynamic wear leveling.  Dynamic wear
leveling is what smartmedia does.  It depends on the filesystem writing
somewhere to move those blocks.  Static wear leveling will also move
blocks that are not written.

However, the exact nature of wear leveling is not disclosed.  And I see
no reason to trust an undisclosed "static and dynamic wear leveling" any
more than I trust smartmedia.

I will even go further and claim that nothing short of a filesystem can
do proper wear leveling across the complete device.  The reason
smartmedia introduced "areas" was to bound the time until it's map is
created and the device can get accessed.  If the map spanned a large
64GB device, access times would go sky-high.

Any method I can imagine to offer good wear leveling will result in
either a filesystem or at least a simplified one-file-system with the
only file being the "block device" exported outward.  So naturally my
answer to the problem is called LogFS. :)

Jörn

-- 
It's not whether you win or lose, it's how you place the blame.
-- unknown
-
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/