Flash disks and FFS layout heuristics

[Matthew Dillon]

:You've talked yourself into pretty much the same mistake that led to
:jffs2, which turned out to be a terrible idea.

    I'm not familiar with jffs2 but a blockmap abstraction in of itself
    just doesn't have the terrible characteristics you are implying.
    The implementations might have been bad but the concept is quite sound.

    Here's a question.  Ok so the best write performance is to essentially
    append to the NAND device.  That's fairly obvious though as long as you
    are able to fully complete a page it doesn't really matter where the
    data goes.  So the main issue is being able to complete a page (since
    you can't rewrite it).

    But how do you index that information?  You can't simply append the
    information to the NAND unless you also have a way to access it.  So
    does the filesystem have to scan the NAND (or significant portions of it)
    in order to build an index of the filesystem topology in system memory?

    No matter what you do you have to index the information *SOMEWHERE*.
    That somewhere is either going to be in-NAND or in-memory or some
    combination of the two.  If it is entirely in-memory you have to scan
    the auxillary information in nearly the entire NAND array to build
    your index.  If it is entirely in-NAND you have a significant updating
    problem.

    A named-block model, done right, can serve as the index.  That is, it
    is exactly the same problem just viewed from a different angle.
    A named-block model does not necessarily imply that the indexing
    topology has to be stored entirely in-NAND, it does not imply any sort
    of linear array, and it does not imply any random-updating requirement.

    I don't know what the jffs2 folks did but you shouldn't take their
    performance failure as an indication that the general concept is
    incorrect.

						-Matt