From owner-cvs-src@FreeBSD.ORG Wed Jul 21 20:45:22 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1E3D16A4CE for ; Wed, 21 Jul 2004 20:45:22 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 8505A43D3F for ; Wed, 21 Jul 2004 20:45:22 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 414 invoked by uid 89); 21 Jul 2004 20:45:19 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 21 Jul 2004 20:45:19 -0000 Received: (qmail 393 invoked by uid 89); 21 Jul 2004 20:45:19 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 21 Jul 2004 20:45:19 -0000 Received: from palm.tree.com (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i6LKjHvX090599; Wed, 21 Jul 2004 16:45:18 -0400 (EDT) (envelope-from ups@palm.tree.com) Message-Id: <200407212045.i6LKjHvX090599@palm.tree.com> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Alfred Perlstein In-Reply-To: Message from Alfred Perlstein of "Wed, 21 Jul 2004 11:34:44 PDT." <20040721183444.GS95729@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jul 2004 16:45:17 -0400 From: Stephan Uphoff cc: src-committers@freebsd.org cc: cvs-src@freebsd.org cc: Scott Long cc: cvs-all@freebsd.org cc: Roman Kurakin cc: Robert Watson cc: Nate Lawson Subject: Re: cvs commit: src/sys/kern kern_shutdown.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 20:45:22 -0000 Alfred Perlstein wrote: > > * Scott Long [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