Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Mar 2008 15:38:46 -0700
From:      Bakul Shah <bakul@bitblocks.com>
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:  <20080331223846.CFD975BAE@mail.bitblocks.com>
In-Reply-To: Your message of "Mon, 31 Mar 2008 22:23:37 -0000." <26080.1207002217@critter.freebsd.dk> 

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Mar 2008 22:23:37 -0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk>  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 sort of the approach Margo Seltzer used for her (Kludge-)LFS
> it has many drawbacks, in particular when it comes to recovery.

[Poul, use positive encouragement and you'd inspire a lot more
people!]

Note that in effect this is exactly what zfs does. Update of
any block implies finding a new place for the updated copy,
which means the block pointing to it must be also updated,
which means a new place for it etc. etc.

But hey, I spent just a few minutes sketching out the idea so
it is possible I missed a whole bunch of things!  If I was
actually implementing this (which I am tempted to...) I'd
certainly want to know what others did.

One thing I forgot to add: I'd let the lower level handle bad
block forwarding and wear levelling (like on the m-tron
device).



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080331223846.CFD975BAE>