skipping fsck with soft-updates enabled

[Scott Oertel]

Brooks Davis wrote:
> On Wed, Jan 10, 2007 at 09:12:15AM -0600, Eric Anderson wrote:
>   
>> On 01/10/07 00:20, Scott Oertel wrote:
>>     
>>> Victor Loureiro Lima wrote:
>>> >From rc.conf man page:
>>>       
>>>> ---
>>>> background_fsck_delay
>>>>                (int) The amount of time in seconds to sleep before 
>>>> starting
>>>>                a background fsck(8).  It defaults to sixty seconds to 
>>>> allow
>>>>                large applications such as the X server to start 
>>>> before disk
>>>>                I/O bandwidth is monopolized by fsck(8).
>>>> ---
>>>>
>>>> You can set the delay as long as you want, so it wont have to start
>>>> right away, in fact it can start as late as a year (if thats really
>>>> what you want ;))
>>>>
>>>> att,
>>>> victor loureiro lima
>>>>
>>>> 2007/1/10, Oliver Fromme <olli at lurza.secnetix.de>:
>>>>         
>>>>> Scott Oertel wrote:
>>>>>           
>>>>>> I am wondering what kind of problems would occur, besides lost 
>>>>>>             
>>>>> space, if
>>>>>           
>>>>>> after a system crash a fsck is skipped. According to the 
>>>>>>             
>>>>> documentation,
>>>>>           
>>>>>> with soft-updates enabled, the file system would be consistant, there
>>>>>> would just be lost resources to be recovered which I am assuming 
>>>>>>             
>>>>> can be
>>>>>           
>>>>>> safely done at a later time to avoid long periods of downtime during
>>>>>> peek hours.
>>>>>>             
>>>>> I think that's exactly what the background fsck feature
>>>>> does.  If you enable it (which is even the default), the
>>>>> fsck process doesn' start right away, so the system comes
>>>>> up in multi-user mode immediately.  Then a snapshot is
>>>>> created on the file system, and fsck runs on the snap-
>>>>> shot, freeing the lost space in the file system.
>>>>>
>>>>> Of course, it only works reliably with soft-updates enabled,
>>>>> _and_ there must not be any unexpected inconsistencies.
>>>>> However, with some common setups (e.g. cheap disks lying
>>>>> about completed write operation) it is difficult to
>>>>> guarantee the consistency.  Soft-updates is rather fragile
>>>>> when the hardware doesn't work exactly as it's supposed to.
>>>>> I've witnessed breakage in the past, and for that reason
>>>>> I always disable the background fsck feature.  And it's the
>>>>> reason I'm looking forward to gjournal to become stable,
>>>>> because it seems to be less fragile in the presence of
>>>>> imperfect hardware.
>>>>>
>>>>> Best regards
>>>>>   Oliver
>>>>>
>>>>> -- 
>>>>> Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
>>>>> Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
>>>>> Any opinions expressed in this message may be personal to the author
>>>>> and may not necessarily reflect the opinions of secnetix in any way.
>>>>>
>>>>> "C++ is to C as Lung Cancer is to Lung."
>>>>>        -- Thomas Funke
>>>>> _______________________________________________
>>>>>           
>>> The problem with background fsck is that on my machines, it doesn't work 
>>> well. These machines have 8x750gb SATA drives and they are under extreme 
>>> stress all the time. When you run fsck in the background each drive 
>>> takes 10+ minutes to create the snapshot file, during which time the 
>>> machine is completely unresponsive, and unstable.
>>>       
>> What version of FreeBSD are you running?  You might try gjournal, which 
>> I've had great luck with, and Pawel (pjd@) is incredibly responsive to 
>> bug reports, etc.
>>
>>     
>>> That is why I am wondering, if it is ok to skip the background fsck's, 
>>> foreground fsck's and reschedule them for a later time, during non peak 
>>> hours.
>>>       
>> I think most people would be nervous to tell you 'sure, skip it until 
>> later', but I can tell you from experience that I myself have delayed 
>> fscking for weeks on end, to do exactly what you want.
>>     
>
> I've been thinking it would be useful to have a new background_fsck_delay
> value of CRON and have a cron job that can accomplish the background
> fsck during off hours if needed.
>
> -- Brooks
>   

I'll probably do some testing with the effects of delaying fsck for long 
periods of time using soft-updates. Personally, I haven't found anyone 
stating any hard facts that would leave me to believe that running on a 
dirty filesystem for an extended period of time won't cause further 
inconsistencies.

Which was what I was hoping to get out of this post, maybe someone will 
read it down the line and provide some real facts of why it is or is not 
dangerous to delay fsck's for an extended period of time.

Thanks for the input..

--Scott