From owner-cvs-src@FreeBSD.ORG Wed Jul 21 21:41:15 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 E352116A4EC for ; Wed, 21 Jul 2004 21:41:12 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27A1C43D53 for ; Wed, 21 Jul 2004 21:41:12 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i6LLcNts070678 for cvs-src@freebsd.org.checked; (8.12.8/vak/2.1) Thu, 22 Jul 2004 01:38:23 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (rik.cronyx.ru [172.22.4.1]) by hanoi.cronyx.ru with ESMTP id i6LLabWc070583; (8.12.8/vak/2.1) Thu, 22 Jul 2004 01:36:38 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40FEE039.8010702@cronyx.ru> Date: Thu, 22 Jul 2004 01:29:29 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Alfred Perlstein References: <200407211604.i6LG4kFK052991@repoman.freebsd.org> <40FE95FD.6000101@cronyx.ru> <40FE9A94.5090805@root.org> <40FE9FFF.6050702@freebsd.org> <20040721183444.GS95729@elvis.mu.org> In-Reply-To: <20040721183444.GS95729@elvis.mu.org> 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: 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 21:41:16 -0000 Alfred Perlstein: >* 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. > Just fresh view or one more crazy stupid idea ;-) Why not to save those 30+ sec data and let user apply it manualy (probably this is possible only for text data) at fsck time or later. We could create a disk in memory put files that would be touched in to it and apply one by one file and see what would happen. This may be usefull for critical data. And this sync_delta could be saved in safe place like crash dump saved. rik