From owner-cvs-all@FreeBSD.ORG Wed Jul 21 16:26:57 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85A1316A4CF; Wed, 21 Jul 2004 16:26:57 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D70543D48; Wed, 21 Jul 2004 16:26:57 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i6LGQGKs057736; Wed, 21 Jul 2004 12:26:16 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i6LGQFK9057733; Wed, 21 Jul 2004 12:26:16 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 21 Jul 2004 12:26:15 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Roman Kurakin In-Reply-To: <40FE95FD.6000101@cronyx.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_shutdown.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 16:26:57 -0000 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 > > > > > > > > > > > >