Date: Mon, 31 Mar 2008 21:05:08 -0400 From: David Schultz <das@FreeBSD.ORG> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Christopher Arnold <chris@arnold.se>, Martin Fouts <mfouts@danger.com>, arch@FreeBSD.ORG, qpadla@gmail.com, freebsd-arch@FreeBSD.ORG Subject: Re: Flash disks and FFS layout heuristics Message-ID: <20080401010508.GA7708@zim.MIT.EDU> In-Reply-To: <26080.1207002217@critter.freebsd.dk> References: <20080331222154.C976C5B50@mail.bitblocks.com> <26080.1207002217@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 31, 2008, Poul-Henning Kamp wrote: > In message <20080331222154.C976C5B50@mail.bitblocks.com>, Bakul Shah writes: > >On Mon, 31 Mar 2008 13:06:10 PDT Matthew Dillon <dillon@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080401010508.GA7708>