Re: Reiser4 status: benchmarked vs. V3 (and ext3)

From: Daniel Egger (degger_at_fhm.edu)
Date: 07/26/03

  • Next message: paul_at_thoughtcriminal.co.uk: "Re: ide problem - is this a known problem, or is the disk dead?" 
    To: Yury Umanets <umka@namesys.com>
Date:	26 Jul 2003 17:21:37 +0200

    Am Sam, 2003-07-26 um 16.54 schrieb Yury Umanets:

    Now we're talking. :)

    > Reiserfs cannot be used efficiently with flash, as it uses block size 4K
    > (by default) and usual flash block size is in range 64K - 256K.

    Don't confuse block size with erase size. The former is the layout of
    the fs' data on the medium while the latter is the granulariy of the
    erase command which is important insofar that flash has to be erased (in
    most cases) before one can write new data on it.

    However since you said that one can plug in a different block allocation
    scheme, I think it might be possible to work around that limitation by
    writing a block allocator which works around the limitations of the
    erase size.

    > Also reiserfs does not use compression, that would be very nice of it
    > :), because flash has limited number of erase cycles per block (in range
    > 100.000)

    I don't see what the compression has to do with the limited number of
    erase/write cycles.

    > and it is about three times as expensive as SDRAM.

    That's true but not important to us. The system right now fits nicely on
    a 128MB CF card when using ext2 or on 64MB when using JFFS2. The latter
    is far more stable and reliable but dogslow. Since the price difference
    between 128MB and 64CF is rather small and the cost of the overall
    system relatively high this is no argument for us.

    > So, it is better to use something more convenient. For instance jffs2.

    Convenient only insofar that it's more reliable. It's a pain in the neck
    to setup for non hardwired flash chips and to boot, it also takes
    forever to mount and to write on it.

    > (1) Make the journal substantial smaller of size.
    > (2) Don't turn tails off. This is useful to prolong flash live.

    Thanks. But first I'll have a look at your plugin architecture to see
    how feasible a different implementation of block allocation especially
    for flash devices would be. 

    -- 
Servus,
       Daniel

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

  • Next message: paul_at_thoughtcriminal.co.uk: "Re: ide problem - is this a known problem, or is the disk dead?"

    Relevant Pages

    • Re: Reiser4 status: benchmarked vs. V3 (and ext3)
      ... > Don't confuse block size with erase size. ... that if an IO request size does not equal to flash ... > However since you said that one can plug in a different block allocation ... Plugin-based architecture is used in reiser4, ...
      (Linux-Kernel)
    • Re: o_sync in vfat driver
      ... flash disks are not stupid as you assume. ... It takes about a second to erase a 64k physical sector. ... device eth0 entered promiscuous mode ... movb $0xaa, 0x555 ...
      (Linux-Kernel)
    • Re: document ext3 requirements
      ... +stay on the disk. ... An inherent problem with using flash as a normal block device is that the ... flash erase size is bigger than most filesystem sector sizes. ...
      (Linux-Kernel)
    • Unable to erase flash HC08
      ... I am unable to erase flash pages on an HC08QT4. ... the 'write to any address in the flash page' part of the erase routine, ... erases your reset vector if the ROM routine is called. ...
      (comp.arch.embedded)
    • Re: Confused about Flash
      ... If I write a secret combination of words to a secret list of addresses ... Apparently I can't do normal reads during erase, ... During erase or program, I again can't execute code out of flash, so ... I'll have to relocate the flash erase and write routines into CPU ram ...
      (sci.electronics.design)