skipping fsck with soft-updates enabled

[Eric Anderson]

On 01/10/07 11:43, 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 think an even better solution is to have a "NONE" option, that never 
does it.  Then, you can just cron it whenever if you wish, or never if 
you wish.  NONE is also more consistent with other rc-like options (I 
think).

Eric


-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
An undefined problem has an infinite number of solutions.
------------------------------------------------------------------------