skipping fsck with soft-updates enabled

[Scott Oertel]

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
>> _______________________________________________
>> freebsd-fs at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>>
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.

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.

Thanks,
Scott