This is a known problem right now and I am working on potential solutions
to it.  Its difficult to know exactly how much disk space you are using in
LFS and how much you have left due to the fact that the amount of space
used by metadata (inode blocks, segment summaries, and the ifile) is
dynamic and can flux around as the filesystem cleaner runs.  At this
point, LFS estimates these numbers based on the state of the fs at the
time the 'df' is done.  While this estimation is quick, its not very good
(especially for large, mostly empty, relatively young filesystems).  The
accuracy of this estimation increases as your filesystem gets older and
fuller, but you can rest assured that the space is definitely is not
*lost*.

//Jesse Off

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
> filesystem of mine.  In addition, the total size of the filesystem, as
> reported by `df' seems to be continuously changing as I copy several
> hundred megabytes of data onto it:
>
>   oreo# df -k /home ; du -sk /home
>   Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
>   /dev/wd0e    42067777   703873 37157127     1%    /home
>   174789  /home
>
> 2 mins later...
>
>   oreo# df -k /home ; du -sk /home
>   Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
>   /dev/wd0e    41492675   730397 36613010     1%    /home
>   181135  /home
>
> In my mind, 181135 KB != 730397 KB.
>
> Is this correct behavior?  And if so, is there any documentaion on how LFS
> works outside of reading the kernel sources?
>
> -brian.
>
>
>