Date: Wed, 21 Jul 2004 12:26:15 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Roman Kurakin <rik@cronyx.ru> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_shutdown.c Message-ID: <Pine.NEB.3.96L.1040721122111.56342C-100000@fledge.watson.org> In-Reply-To: <40FE95FD.6000101@cronyx.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Principal Research Scientist, McAfee Research > > rik > > 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 > > > > > > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040721122111.56342C-100000>