I have been working on this problem (and others) for Konrad.  Basically,
what it means is that your cleaner was not able to clean as fast as your
filesystem is filling up.  Theres a point where LFS stops all filesystem
activity to run the cleaner, but there are problems right now in knowing
exactly when to do this as the cleaner also needs free space to do its
work (and sometimes, albeit rare, the cleaner can use more space than it
actually frees).  There is also a potential for this problem if your
filesystem has lots of segments and your segment usage table is too big
to fit in one disk block, but that something I haven't supplied a fix to
yet but should also be a very rare occurence.

Free space accounting is very tricky in LFS.  What is shown in a df is
only an estimate of how much space you have left.  Also, there could be
a number of supposedly 'free' bytes shown that are still effectively
locked away in dirty segments that the cleaner has yet to get to.   

My test machines have seen almost every type of LFS crash, and I've seen
my share of this one.   I've fixed one of the things that can cause this
in a patch of fsck_lfs and /syssrc/ufs/lfs/lfs_vfsops.c that I believe
Konrad has merged in -current, but I still
am able to reproduce this myself even with these patches.   The fact is,
that LFS isn't very friendly right now when space gets low.  There are
at least 4 known spots where NetBSD 1.5 LFS actually 'leaks' free
space.  Luckily, our fsck can detect and fix the 'avail' count, but
still... this is not good.  
  


//Jesse Off



 

     


> > On Sun, 19 Nov 2000, Manuel Bouyer wrote:
> >
> > > > It actually looks like there isn't enough inodes or something similiar.
> > > > Should not cause a panic though. :)
> > >
> > > How much free space do you have ? LFS isn't really happy when the disk
> > > is nearly full.
> >
> > When pkgsrc is untared I've used 30% of the space. (But 79% of the inodes
> > if I use ffs, but that takes AGES)
> >
> >