Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Jul 2004 14:51:37 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Alfred Perlstein <alfred@FreeBSD.org>
Cc:        Nate Lawson <nate@root.org>
Subject:   Re: cvs commit: src/sys/kern kern_shutdown.c
Message-ID:  <40FEE569.2010209@elischer.org>
In-Reply-To: <200407212045.i6LKjHvX090599@palm.tree.com>
References:  <200407212045.i6LKjHvX090599@palm.tree.com>

next in thread | previous in thread | raw e-mail | index | archive | help


Stephan Uphoff wrote:

>Alfred Perlstein wrote:
>  
>
>>* Scott Long <scottl@freebsd.org> [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
>
>  
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40FEE569.2010209>