[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/53861: regular kernel panic (ffs_blkfree: bad size)
The following reply was made to PR kern/53861; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
Subject: Re: kern/53861: regular kernel panic (ffs_blkfree: bad size)
Date: Mon, 14 Jan 2019 06:09:39 +0000
On Sun, Jan 13, 2019 at 03:45:01PM +0000, Manuel Bouyer wrote:
>> I did and fsck found some errors. More than that - I had to check
>> big partition (more than 5Tb) twice, because first run failed
>> overwhelming with "Can't read sectors" error showing negative
>> block numbers.
>> It appears bug should be closed, however I am still very concerned
>> about using log filesystem in production. Isn't that a stuation,
>> which should be prevented by log?
> Not in all case; only if the unclean shutdown if from an external
> cause (e.g. power loss). I've seen this kind of issue with
> different log filesystems, and linux sets a flag on disk when it
> runs into a filesystem inconsistency to force fsck on next reboot.
Well, properly speaking, a journaled fs should survive any crash,
including one it caused itself, because the whole point of the journal
is to make the updates to the disk atomic with respect to file system
However, that only really works if the journaled fs has no journaling
or recovery bugs.
It also relies on assumptions about the disk working correctly which
real hardware sometimes occasionally violates.
So yes, something had to break somewhere for this to happen; it might
or might not have been wapbl... unfortunately by the time you notice
and think to run fsck it's effectively impossible to guess what
happened originally, and all the more so on a huge volume.
For production use though the first thing most people worry about is
that wapbl doesn't recover file data (same as traditional ffs) and
this can cause various problems after a crash.
David A. Holland
Main Index |
Thread Index |