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:	Tue, 12 Jun 2007 16:29:51 +0300
From:	Eduard-Gabriel Munteanu <maxdamage@...din.ro>
To:	Juergen Beisert <juergen127@...uzholzen.de>
CC:	linux-kernel@...r.kernel.org, lkml@...009.com
Subject: Re: ext2 on flash memory

*This message was transferred with a trial version of CommuniGate(r) Pro*
Juergen Beisert wrote:
> So it makes no sense to find the best filesystem for such a case. 
> There is no best one.

It does make sense. Wear leveling isn't the only thing that matters. An 
important criteria is the total amount of wear that you get when using a 
filesystem. Some filesystems are simply not suitable: they either write 
too often to disk (though, as I said, this can be alleviated by COW-ing 
it or working on a copy and then updating the flash drive), or a single 
operation requires too many changes to its image/structure. Normal fs-s 
often change their internal structure, trading for space efficiency or 
speed. Better storage and accounting of data involve more complicated 
internal fs structures, that aren't too stable over time (that is, they 
change often and much).

For example, an ISO9660 multisession rewritable CD/DVD trades space 
efficiency and flexibility for a lower wear and better wear-leveling. 
This is obvious, as the user triggers flushes to disk (that is, burning 
a new session) with a lower frequency, when his work is done, and the 
writes are always done sequentially (=> wear leveling). I'm not saying 
anything about UDF, since I don't know much about it.
-
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/