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
USENIX paper?

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
>needed.

Mmm. that'd be nice.