From owner-freebsd-fs@FreeBSD.ORG Sun May 20 21:39:58 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3657216A400 for ; Sun, 20 May 2007 21:39:58 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id DA33413C465 for ; Sun, 20 May 2007 21:39:57 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l4KLdqGT078009; Sun, 20 May 2007 15:39:54 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4650C028.9060400@samsco.org> Date: Sun, 20 May 2007 15:39:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Gore Jarold References: <653845.99663.qm@web63012.mail.re1.yahoo.com> In-Reply-To: <653845.99663.qm@web63012.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 20 May 2007 15:39:54 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-fs@freebsd.org Subject: Re: dangers of delaying an fsck on busy fileserver ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2007 21:39:58 -0000 Gore Jarold wrote: > --- Scott Long wrote: > >> Gore Jarold wrote: >>> --- Scott Long wrote: >>> >>> >>>> In an ideal world, the only consequence of >> delaying >>>> bgfsck is that >>>> not all filesystem blocks will be marked free >> that >>>> should be. So >>>> if you deleted a large tree of files before the >>>> crash, those blocks >>>> might still show up in use until bgfsck >> completes. >>> >>> Thank you. Would _you_ do this with valuable data >> ? >> Very good question =-) If you're using softupdates >> then any >> damage will have been done when the hard shutdown >> happens; bgfsck >> won't create any new damage. The biggest problem of >> bgfsck beyond >> the i/o slowness and near deadlocks that it can >> create (modulo the >> fixes that the Kostik is working on) is that if it >> does encounter >> damage that it can't fix automatically, it exits and >> leaves the >> filesystem inconsistent. So you need to keep a very >> close eye on >> your logs and check for this, then schedule downtime >> when it happens >> so you can babysit a full fsck. > > > Ahhh... I think you may have misunderstood my original > question. What I am saying is, I don't _ever_ want to > do a background fsck. My systems are too busy (and > have too large of disks) to deal with the (current) > baggage of making a 4 TB snapshot and then > bg_fsck'ing. > > What I am saying is the following: > > - I set background_fsck_delay="86400" > > - I tell datacenter techs NOT to call me when the > system crashes - just to hit reset. > > - users bang on the system, as normal, for X hours - > all the while the filesystems are _dirty_ and nothing > is being done about it > > - I wake up hours later, unmount the filesystems, and > foreground fsck them > > My goal in all of this is to keep from being woken up > in the middle of the night. I don't care about the > downtime to the system when I eventually do foreground > fsck them, I just don't want to do it in the middle of > the night _and_ I don't want my users to have to sit > around waiting for me to do the fsck _on top of_ the > fsck downtime itself. > > So ... comments ? I _suspect_ the conclusions are > about the same - running on a dirty FS is the same as > running on a dirty FS while being bg_fsck'd ... but I > want to make sure... > So yeah, the only consequence of doing the preen but not the bgfsck is that you might loose some free space after a crash. How much depends on your workload. If you're deleting large files or large trees of files, the loss might be significant. It sounds like you understand how to manage that, though, so it'll probably be a fine solution for you. Scott