cvs commit: src/sys/kern kern_shutdown.c
rwatson at FreeBSD.org
Wed Jul 21 09:26:57 PDT 2004
On Wed, 21 Jul 2004, Roman Kurakin wrote:
> How to change behavior?
When we're in a "panic" state, we will no long attempt to call out to all
file systems to synchronize their on-disk data with in-memory data. This
was unreliable in many circumstances because panic() can be called from
some interesting places, such as in the scheduler, interrupt handlers, in
the file system code, etc, and those circumstances were not conducive to
reliable syncing of disks. For an example of what happens as a result of
syncing in panic(), take a look at PR kern/69369.
Assuming that the sync() call did work, you would be more likely to have
in-memory buffers on disk following the panic(), which would reduce the
level of potential data loss resulting from panic()'ing with a lot of data
in buffers that needs to go to disk.
Bruce and I exchanged some e-mail (or more accurately: Bruce explained
things to me) regarding the relationship between the debugger environment
and some of the things we'd like to be able to do from there. The
concerns raised are very similar to the ones raised in the discussion of
network kernel debugging and console: how to reliably interact with device
drivers (et al) under messy circumstances.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org Principal Research Scientist, McAfee Research
> Robert Watson wrote:
> >rwatson 2004-07-21 16:04:46 UTC
> > FreeBSD src repository
> > Modified files:
> > sys/kern kern_shutdown.c
> > Log:
> > Don't sync the file system on panic by default. This seems to basically
> > work very infrequently, and often results in a compound panic which
> > confuses debugging; locking/SMP have made the layering violation (and
> > risks) of this more obvious over time.
> > Discussed with: green, bde, et al.
> > Revision Changes Path
> > 1.160 +1 -1 src/sys/kern/kern_shutdown.c
More information about the cvs-all