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

This sounds really bad and like the design is inherently broken. 
Perhaps it's better to simply retire LFS completely and put efforts into 
importing a different logged/journalled filesystem that's known to not 
have these kind of problems?  There're several around that could be used 
as a basis, or at least for getting ideas from, like, for example, XFS, 
or IBM's JFS etc.

mkb.