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]

Message-Id: <200706120953.03735.juergen127@kreuzholzen.de>
Date:	Tue, 12 Jun 2007 09:53:03 +0200
From:	Juergen Beisert <juergen127@...uzholzen.de>
To:	linux-kernel@...r.kernel.org
Cc:	"Kevin Bowling" <lkml@...009.com>
Subject: Re: ext2 on flash memory

On Tuesday 12 June 2007 02:35, Kevin Bowling wrote:
> All of the posts fail to address the question here: what is the
> correct file system, or does one exist yet, for wear leveling flash
> storage.
> JFFS2 and logfs are nice for MTD, but for better flash 
> memories that are likely to be used in the future like solid state
> hard disks, what is the answer?

As long the device itself does the wear leveling, there could no specific 
answer here!
On MTD its the job of the filesystem to do the wear leveling because it works 
on the bare flash. But memory sticks, CFs and so on emulate a block device. I 
don't know a device where you could switch off its internal wear leveling 
mechanism. So it makes no sense to find the best filesystem for such a case. 
There is no best one.

Its the same discussion about protecting essential data on CF by using more 
than one partition. A first partition for read only (system), a second one 
also for writing (data). And everyone hopes in the case of a crash the read 
only partition survives. But CFs internal wear leveling does not know 
partitions and continuous to use *all* blocks on the CF for its job.

Juergen
-
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/