cvs commit: src/sys/kern kern_shutdown.c

[Julian Elischer]

Stephan Uphoff wrote:

>Alfred Perlstein wrote:
>  
>
>>* Scott Long <scottl at 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
>
>  
>