[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/37955: Kernel Panic NetBSD 4.0 blkfree
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>
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.)
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?
Main Index |
Thread Index |