Subject: Re: Questions on NetBSD's LFS filesystem behavior.
To: Brian Chase <bdc@world.std.com>
From: Konrad Schroder <perseant@hhhh.org>
List: tech-kern
Date: 01/24/2001 17:14:28
On Wed, 24 Jan 2001, Brian Chase wrote:

> Maybe this is just a fundamental misunderstanding of how LFS works on my
> part, but I'm seeing some significant discrepancies between the disk
usage
> reported by `df' and the actual disk usage reported by `du' on an LFS

Oreo runs NetBSD 1.5?

I can explain the change over time, which will be (mostly) fixed for
1.5.1; the gross discrepancy between df's Used value and du's value is
more difficult to explain unless certain things went wrong with the
filesystem up to this point.

The fundamental issue here is that while other filesystems (e.g. FFS) used
fixed amounts of metadata (inodes), LFS uses dynamically allocated
metadata (inodes and segment summaries), so the amount of data that can
actually fit on the filesystem may change over time.  This is what causes
the difference in df's first column.

Also, if segment summaries are being written when little real data is
being written, the disk can appear to shrink because the metadata/data
ratio is higher than expected; the cleaner when it wakes up will fix this,
appearing to increase the size of the disk again.  (This is independent of
the cleaner's intended function which is to make sure that there is
somewhere to write when the log "wraps around" to the front of the disk
again.)

> In my mind, 181135 KB != 730397 KB.

While the number reported by df will always be higher than the one
reported by du, it shouldn't be this different: obviously something is
wrong here.  I suspect that df is just not reporting the right value
because of the way the metadata is projected, a problem that Jesse Off is
looking at; if this is the case, when the cleaner wakes up (which may not
happen for a while since your filesystem is mostly empty) it will probably
drop this number back to a more reasonable value (and as your filesystem
fills and ages this will become less of a problem).

You can hurry the cleaner up in this respect by killing it, and then
running one manually using

	/usr/libexec/lfs_cleanerd -b -l1 -d

for a while; it should tell you how many segments are clean/dirty and what
it is doing about it.  If that doesn't seem to have any effect, I'd
suggest compiling fsck_lfs from -current and running it on the filesystem,
which should at least be able to tell you if the number of clean segments,
or the recorded number of dirty metadata blocks, are incorrect.

> Is this correct behavior?  And if so, is there any documentaion on how LFS
> works outside of reading the kernel sources?

If you like, take a look at the papers listed at
http://www.hhhh.org/perseant/lfs.html, and/or the LFS section in the red
daemon book.
						Konrad Schroder
						perseant@hhhh.org