UFS corruption panic

Daniel O'Connor doconnor at gsoft.com.au
Sun Jan 15 12:08:15 UTC 2012


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.
> 
> In other words: don't do that then :-)

OP didn't do anything silly, it really is a bug from the user POV.

From 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








More information about the freebsd-stable mailing list