From owner-cvs-all@FreeBSD.ORG Wed Jul 21 21:57:55 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 198A916A4CE; Wed, 21 Jul 2004 21:57:55 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B91443D3F; Wed, 21 Jul 2004 21:57:52 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.200] ([192.168.0.200]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6LM3vZs064703; Wed, 21 Jul 2004 16:03:57 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <40FEE6CA.3090005@samsco.org> Date: Wed, 21 Jul 2004 15:57:30 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040702 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <200407212045.i6LKjHvX090599@palm.tree.com> <40FEE569.2010209@elischer.org> In-Reply-To: <40FEE569.2010209@elischer.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: Alfred Perlstein 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-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 21:57:55 -0000 Julian Elischer wrote: > > > Stephan Uphoff wrote: > >> 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. >> > > If you have no sync then you are more likely to have a successful > core-dump.. > so write a utility that extracts the missing data from the corefile ! > > :-) > Implementing a journalling filesystem would be a much more beneficial use of time here. Scott