From owner-cvs-all@FreeBSD.ORG Wed Jul 21 21:51:38 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 89B6216A4CE; Wed, 21 Jul 2004 21:51:38 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37C4843D1F; Wed, 21 Jul 2004 21:51:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E4F1C7A49E; Wed, 21 Jul 2004 14:51:37 -0700 (PDT) Message-ID: <40FEE569.2010209@elischer.org> Date: Wed, 21 Jul 2004 14:51:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Alfred Perlstein References: <200407212045.i6LKjHvX090599@palm.tree.com> In-Reply-To: <200407212045.i6LKjHvX090599@palm.tree.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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-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:51:38 -0000 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 ! :-) > > > Stephan > > >