At Mon, 3 Jun 2002 21:16:58 -0700 (PDT),
Konrad Schroder wrote:
> 
> On Mon, 3 Jun 2002, gabriel rosenkoetter wrote:
> 
> > /dev/wd0a   127195868 41428750  73047532    36%    /mp3
> [...]
> > NetBSD grappa 1.5ZC NetBSD 1.5ZC (GRAPPA) #4: Fri Apr  5 17:58:15 EST 2002     gr@grappa:/usr/obj/.i386/sys/arch/i386/compile/GRAPPA i386
> 
> If this is the problem I think it is, I think if you upgrade lfs_cleanerd
> to later than 20020426 or so, it won't do this any more.

I experienced similar behavior yesterday, while running build.sh with
OBJDIR and DESTDIR set in LFS.  At that time lfs_cleanerd binary was 3
months old.  I installed the newly built one and did:
	# kill <lfs_cleanerd PID>
	# /usr/libexec/cleanerd -d -n 4 /path/to/lfs
	^C  (the situation looked same)
	# /usr/libexec/cleanerd -d -n 16 /path/to/lfs
The cleanerd was trying to clean ~75% filled segments, and with
 "-n 16", the cleanerd idled after a while.

I thought it was all right and restarted the cleaner with the default
"-b -n 4" flags, but the machine paniced ~20 hours later.
And now, ifile seems broken (fsck_lfs reports many inode freelist
inconsistencies along with a few segment byte count inconsistencies).

The panic was "lfs_updatemeta: negative bytes" in lfs_cleanerd, IIRC.
The panic was probably soon after the following syslog.

Jun  6 13:13:24 kiku lfs_cleanerd[6022]: clean_segment: lfs_markv
failed: Resource temporarily unavailable
Jun  6 13:21:24 kiku lfs_cleanerd[6022]: clean_segment: lfs_markv
failed: Resource temporarily unavailable
Jun  6 13:31:16 kiku lfs_cleanerd[6022]: clean_segment: lfs_markv
failed: Resource temporarily unavailable
Jun  6 13:51:52 kiku last message repeated 7 times

And the partition in question is:
/dev/wd0h     4985071  3273007   1213557    72%    /export/kiku

Any clues?

--
IWAMOTO Toshihiro