Re: kern/37955: Kernel Panic NetBSD 4.0 blkfree

[Vincent van den Berg <vincent%mijnpostvak.in@localhost>]

The following reply was made to PR kern/37955; it has been noted by GNATS.

From: Vincent van den Berg <vincent%mijnpostvak.in@localhost>
To: David Holland <dholland-bugs%netbsd.org@localhost>
Cc: 
Subject: Re: kern/37955: Kernel Panic NetBSD 4.0 blkfree
Date: Mon, 10 Mar 2008 13:31:52 +0100

 David Holland schreef:
 > On Wed, Mar 05, 2008 at 12:00:05PM +0000, Vincent van den Berg wrote:
 >  > From: Vincent van den Berg <vincent%mijnpostvak.in@localhost>
 >  > To: gnats-bugs%NetBSD.org@localhost
 >  > Subject: Re: kern/37955: Kernel Panic NetBSD 4.0 blkfree
 >  > Date: Wed, 05 Mar 2008 12:56:59 +0100
 >  > 
 >  >  It just happened again, with a clean file system while using rsnapshot! 
 >  >  I think this is a serious bug.
 >
 > Just to check, when you say clean, you mean like this, right?
 >    # fsck -f /dev/rwd0f
 >    ** /dev/rwd0f
 >    ** File system is already clean
 >    ** Last mounted on /scratch
 >    ** Phase 1 - Check Blocks and Sizes
 >    ** Phase 2 - Check Pathnames
 >    ** Phase 3 - Check Connectivity
 >    ** Phase 4 - Check Reference Counts
 >    ** Phase 5 - Check Cyl groups
 >    1 files, 1 used, 253998 free (14 frags, 31748 blocks, 0.0% fragmentation)
 >    # 
 >
 > That is, it fscks cleanly, rather than merely this:
 >    # fsck /dev/rwd0f
 >    ** /dev/rwd0f
 >    ** File system is clean; not checking
 >    # 
 >
 > because the clean bit in the superblock only means the fs is correct
 > if there are no bugs in either the kernel or fsck. Which would be a
 > nice thing to be able to claim, but isn't true.
 >
 > (And I believe if you mount a volume without fscking it and then
 > unmount it, it will subsequently purport to be clean, even though it
 > may in fact be nothing of the sort.)
 >
 >   
 Hi David,
 
 Yes, I forced fsck on all volumes. It goes through them like you 
 described (Phases etc.) and it gives no errors.
 
 Today I noticed that I don't get the kernel panic while dumping a backup 
 to the external drive using the classic dump/restore utilities. However, 
 I ran it for the first time last night, so I'll keep you informed about 
 any future errors that may come up. This maybe indicates that it is 
 related to rsnapshot specifically. Or maybe the combination rsnapshot / 
 ffs / kernel doesn't play well. rsnapshot creates hard-links to files 
 which haven't been changed since the last run, maybe this causes the 
 file system corruption?
 
 Regards,
 
 Vincent