Flash disks and FFS layout heuristics

[David Schultz]

On Mon, Mar 31, 2008, Poul-Henning Kamp wrote:
> In message <20080331222154.C976C5B50 at mail.bitblocks.com>, Bakul Shah writes:
> >On Mon, 31 Mar 2008 13:06:10 PDT Matthew Dillon <dillon at apollo.backplane.com>  wrote:
> >>     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?
> >
> >One possible way:
> >
> >I'd design the system so that each update ends with the write
> >of a root block[1]. 

This is exactly what ZFS does (except that it wasn't designed for
flash, so the primary copy of the root block is always stored at a
well-known location.) Countless other systems dating back to the
use of shadow paging in System R use the same technique, including
WAFL and several flash file systems.

> This is sort of the approach Margo Seltzer used for her (Kludge-)LFS
> it has many drawbacks, in particular when it comes to recovery.

Generally not. Recovery is trivial, especially compared to other
techniques such as journalling. You simply find the root block,
and it has pointers to a consistent snapshot of the system.  The
main limitation is that making updates durable immediately (i.e.,
fsync()) is inefficient, since all the dirty indirect blocks up to
the root need to be flushed to disk. ZFS addresses this by writing
updates that must be synchronous to a logical redo log, which does
introduce complications for recovery.