UFS corruption panic
stb at lassitu.de
Sun Jan 15 08:12:08 UTC 2012
Am 15.01.2012 um 05:20 schrieb Joe Holden:
> Is a panic **really** appropriate for a filesystem that isn't even in
> panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry
> Which happened to be an file-backed md volume that got changed as I forgot
> to unmount it beforehand, however as a result there is now inconsistencies
> and probably data corruption or even missing data on other important
> filesystems (ie; /, /var etc) because there wasn't even a sync or any kind
> of other sensible behaviour.
Yes, a panic is the correct action here. While I agree that it's super annoying, the filesystem notices that something is *really* wrong. Instead of letting the problem fester and continue to corrupt data, it stops the system.
Most filesystems work under the assumption that they're the sole owner of the disk. This means that any changes to the on-disk data must come from filesystem code itself; if that data is inconstistent, it must be a bug in the filesystem code. At this point, panic is the only course of action to avoid even greater damage to the data.
In other words: don't do that then :-)
Stefan Bethke <stb at lassitu.de> Fon +49 151 14070811
More information about the freebsd-stable