cvs commit: src/sys/kern kern_shutdown.c

[Scott Long]

Julian Elischer wrote:
> 
> 
> 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 !
> 
> :-)
> 

Implementing a journalling filesystem would be a much more beneficial
use of time here.

Scott