skipping fsck with soft-updates enabled

[Eric Anderson]

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.

Eric



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