On Fri, Feb 18, 2005 at 04:54:13PM -0700, Jesse Off wrote:
> 
> Indeed, the worst case scenario is pretty bad: take for instance a segment 
> being cleaned with every non-obsolete block being a large offset file block 
> for a different inode.  Moving each block results in having to rewrite 2 
> indirect blocks and its inode block.  If the blocks aren't in the segment 
> being cleaned, LFS now has to find space for 3 extra meta-data blocks to 
> move this particular block.  In test cases, I've seen this result in a 
> vicious cycle that makes the filesystem unuseable with well less than 75% 
> full filesystems.  (I can't remember the exact tests I used, its been a few 
> years...)

Of course, most of this trouble was "earned" in the transition from the
original Sprite LFS to the BSD LFS.  The Sprite LFS didn't keep inodes
in data segments, so that form of this problem could not occur.

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.

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.

Thor