From owner-freebsd-fs@FreeBSD.ORG Mon May 21 04:26:33 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 D059D16A46E for ; Mon, 21 May 2007 04:26:33 +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 7E51D13C46A for ; Mon, 21 May 2007 04:26:33 +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 l4L4QShV084063; Sun, 20 May 2007 22:26:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46511F74.4090303@samsco.org> Date: Sun, 20 May 2007 22:26:28 -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: Eric Anderson References: <653845.99663.qm@web63012.mail.re1.yahoo.com> <46511843.4010205@freebsd.org> In-Reply-To: <46511843.4010205@freebsd.org> 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 22:26:29 -0600 (MDT) X-Spam-Status: No, score=-1.0 required=5.5 tests=ALL_TRUSTED,WHILE_YOU_SLEEP 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, Gore Jarold 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: Mon, 21 May 2007 04:26:33 -0000 Eric Anderson wrote: > On 05/20/07 15:28, 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 can't you turn off background fsck, and set fsck_y_enable="YES"? That > would allow your NOC to hit reset, and it'll come back and fsck in the > foreground while you sleep. > > Eric > > It sounds like he's trying to avoid the immediate downtime that a fgfsck represents and instead defer it to a later time when it's more convenient. In theory, UFS+SU should allow this. Scott