Re: [RFC] LogFS

On Thu, 24 August 2006 21:51:11 -0700, Andrew Morton wrote:
On Thu, 24 Aug 2006 17:54:34 +0200
Jörn Engel <joern@xxxxxxxxxxxxxxxxxxxx> wrote:

Linux needs a decent flash filesystem.

Would http://nilfs.org/en/ be useful on flash?

I am having trouble answering that question, but feel inclined to
answer no.

They don't have a cleaner yet. After my experience and looking at
their data structure, I wish them luck to succeed without a change to
the on-disk format. Most likely they will be unable to prove
correctness and take the standard approach of keeping "some amount" of
space reserved and hoping for the best.

Btrees are an interesting idea.

Buffer heads are a fairly pointless thing when dealing with flash.

Plus my general feeling is that they care only about hard disks and
optimizations for disks and flash are quite different. In the future,
it might make sense to have a generic log-structured filesystem that
works splendidly on both. But I see merit in optimizing each on its
own until it is clear which details work for both and which don't.

Jörn

--
Good warriors cause others to come to them and do not go to others.
-- Sun Tzu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: NAND flash misery
    ... I didn't encounter this problem until we started to use the high capacity CF cards. ... Since the flash iself is hidden behind the IDE interface and a compatible file system, and the read/write performance is critical, it is generally impossible to apply an error correction scheme. ... The same thing is done with hard disks - the controller detects bad blocks, ... CF cards and other earlier flash devices are not that great at wear levelling and bad block handling. ...
    (comp.arch.embedded)
  • Re: NAND flash misery
    ... A HDD has one big problem: the lifetime tends to go to the end when it ... a flash card is easy to swap. ... 256 GB and bigger flash disks, even high quality hard disks are no ...
    (comp.arch.embedded)
  • Re: NAND flash misery
    ... a flash card is easy to swap. ... wear, the longer the lifetime, and the more you read rather than write, ... is really no point to bother about the wear leveling. ... 256 GB and bigger flash disks, even high quality hard disks are no ...
    (comp.arch.embedded)
  • Re: NAND flash misery
    ... I didn't encounter this problem until we started to use the high capacity CF cards. ... Since the flash iself is hidden behind the IDE interface and a compatible file system, and the read/write performance is critical, it is generally impossible to apply an error correction scheme. ... Each sector in NAND has extra space for error correction and detection. ... The same thing is done with hard disks - the controller detects bad blocks, ...
    (comp.arch.embedded)
  • Re: NAND flash misery
    ... Do you know how reliable are the IDE flash drives? ... HDDs wear out through use. ... For common desktop usage, a 32 GB flash disk will probably far outlast a typical hard disk - with 256 GB and bigger flash disks, even high quality hard disks are no longer competitive on reliability and lifetime for real applications. ...
    (comp.arch.embedded)