Subject: Re: LFS (was Thank you NetBSD)
To: None <email@example.com>
From: Jonathan Stone <firstname.lastname@example.org>
Date: 02/23/2005 07:56:19
In message <20050223142242.GA17302@panix.com>,Thor Lancelot Simon writes:
>I don't remember if it used indirect blocks. Greg Oster and I were
>talking about killing off fragments from our LFS and trying to eliminate
>indirect blocks by using extents. It is not 100% clear how this ought
>to work, but with those two key changes (go back to the Sprite way of
>storing inodes, and, as far as possible, block indirection) a lot of
>the hair in the code could go away.
Um. Didn't Margo Seltzer et al. claim that BSD-LFS storing inodes in
the ifile reduced hairiness (relative to Mendel's Sprite-LFS) by
eliminating much special-case handling for inodes? Mabye in the 1993 Winter
I seem to recall a claim that BSD-LFS putting inodes into the ifile
(readonly to userspace, written into the log by the kernel like any
other file, iirc) reduces seek activity measurably, relative to
Sprite-LFS with inodes in a separate, fixed on-disk datastructure.
I'm not saying you are wrong, but how would you respond to those
points (assuming dim memory serves and I am not mis-recorrecting)?
(Me, I think it'd make a good Ph.D Quals exam question...)
>Coincidentally, you would end up with something that looked even more
>like WAFL than LFS already does. And you would end up with a bunch of
>the data structures needed to build another simple, extent-based
>filesystem that could replace FFS for large devices, which is sorely
Mmm. that'd be nice.