Date: Sun, 15 Jan 2012 22:27:23 +1030 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Stefan Bethke <stb@lassitu.de> Cc: freebsd-stable@freebsd.org, Joe Holden <jwhlists@gmail.com> Subject: Re: UFS corruption panic Message-ID: <2D076869-AE11-4205-9FAA-9BEACC8F9720@gsoft.com.au> In-Reply-To: <3BCC7D95-F0BC-447D-9828-DD5B6A07A54A@lassitu.de> References: <CAD-04WOKH6yb0tjcM=pu86kzTfFej%2Bc0E-v9AMC9VyEDn4HSOg@mail.gmail.com> <3BCC7D95-F0BC-447D-9828-DD5B6A07A54A@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15/01/2012, at 18:42, Stefan Bethke wrote: > 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. >=20 > In other words: don't do that then :-) OP didn't do anything silly, it really is a bug from the user POV. =46rom the kernel programmer POV it might not be, and certainly wasn't. = Times change though, every disk media is hot swappable these days, and = in any case assumptions change. That said, changing all those code paths which panic because of = corruption to instead re-mount read only (or similar) is a decidedly non = trivial task :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2D076869-AE11-4205-9FAA-9BEACC8F9720>