cvs commit: src/sys/kern kern_shutdown.c

[Stephan Uphoff]

Alfred Perlstein wrote:
> 
> * Scott Long <scottl at freebsd.org> [040721 09:57] wrote:
> > 
> > It should be noted that syncing on panic is almost never a good idea.
> > The whole idea of panic() is to signal that the system has gotten into
> > an inconsistent and unrecoverable state.  Do you really want to trust it
> > to spam your drive with buffers that are in an unknown state via a set
> > of codepaths that are in an unknown state?  It's much better to just
> > step back and let fsck try to repair the damage.  I can't remember a
> > single time in the last 4 years when a panic actually successfuly synced
> > out all of the buffers and shutdown the filesystem, so it's not likely
> > that you'll avoid a fsck on reboot with this.
> 
> It's not about avoiding a fsck, it's about recovering the last 30+ seconds
> of disk activity.  Ie, files you've just created and such.

Locking is disabled during a sync on panic.
( all lockmgr requests succeed)

Even if the internal file system state is not corrupted
in a panic, multiple threads might be active in the filessystem
using locks to carefully update buffers or enforce the buffer
write order.

A sync requests trampling through the file systems with
total disregard for any locks can do interesting things
to a filesystem on disk.

I think adding a "dangerous" warning to the sysctl description 
might be useful.
Otherwise it is hard to guess that by trying to save 30 seconds of
data one risks loosing the whole file system.


	Stephan