I'm not going to have lots of time to work on LFS this week, but I'd like
to get (and give) more info on these problems ....

On Mon, 19 Apr 1999, Charles M. Hannum wrote:

> It seems to be operating a bit better, but there are a few things I
> notice:
> 
> * I get `lfs_vflush: flushing VDIROP, this shouldn't be' fairly often.
>   A very unscientific sampling indicates that the cleaner has run
>   recently whenever this happens.  (One of the processes is in `S'
>   state rather than `I' state.)

Like the diagnostic says, this should not ever happen during the normal
course of LFS operation...if it does, the checkpoints are not
guaranteed to be valid, so the filesystem can be corrupted if the machine
crashes.

OTOH I haven't used a wide variety of tests yet, so there may well be
cases I've overlooked.  What sort of job(s) are you running on the
filesystem when you get these messages?

> * Every `sync' causes 8k(+1k) to be used, even if the file system is
>   otherwise idle.  This seems poor.

Well, yes.  Every sync means a synchronous checkpoint, which means that
the Ifile inode has to be written, as well as the segment usage table
entry for the current segment, (perhaps) the ifile block containing the
number of clean segments, and a segment summary...three fs-blocks and one
disk block.  df will only report the inode block and segment summary,
since the others just replace their older versions with no net loss...thus
8k+512 for every sync.

This particular case, of update running on an idle filesystem, could
probably be optimized away, if the LFS had some idea of whether anything
had been written since the last checkpoint (and if nothing, then don't
bother to do anything but write the superblock, if even that).

OTOH, each of these writes invalidates the last one, so a segment full of
these sync writes will incur no cleaning cost by the cleaner---so you'll
mysteriously get the lost space back later.  And if there are any writes
going on other than the sync, you'll have to eat that space until the
cleaner runs.

> * Trying to fill the file system with `dd if=/dev/zero bs=64k' and `dd
>   if=/dev/zero bs=1k' simultaneously causes the cleaner to munch
>   really hard, and then eventually panic with `lfs_nextseg: no clean
>   segments'.

This is a hard one to solve, because if you get it it means that although
space exists on disk that could be reclaimed for the pending write, the
cleaner is not able to make usable space by cleaning segments.  The really
sad part is that sometimes the cleaner can actually *lose* space, due to
fragmented metadata; and this is most likely to happen when the filesystem
is close to full.  Alternative cleaning strategies ("hole-plugging" from
Neefe's 1997 paper, or file coalescing during idle periods) could help
with this, but the full disk case is probably the worst one for any LFS.

Or, it's possible the block accounting could be screwed up and it might
think space is available when there is not. 

> I'm sure I'll get bitten by something else.  B-)

Yes, I'm sure there are bugs yet ....

						Konrad Schroder
						perseant@hhhh.org