skipping fsck with soft-updates enabled

[Brooks Davis]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070110/5dc08231/attachment.pgp