Date: Sun, 15 Jan 2012 09:12:05 +0100 From: Stefan Bethke <stb@lassitu.de> To: Joe Holden <jwhlists@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: UFS corruption panic Message-ID: <3BCC7D95-F0BC-447D-9828-DD5B6A07A54A@lassitu.de> In-Reply-To: <CAD-04WOKH6yb0tjcM=pu86kzTfFej%2Bc0E-v9AMC9VyEDn4HSOg@mail.gmail.com> References: <CAD-04WOKH6yb0tjcM=pu86kzTfFej%2Bc0E-v9AMC9VyEDn4HSOg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 15.01.2012 um 05:20 schrieb Joe Holden: > Guys.... >=20 > Is a panic **really** appropriate for a filesystem that isn't even in > fstab? >=20 > ie; > panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry >=20 > 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 --=20 Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BCC7D95-F0BC-447D-9828-DD5B6A07A54A>