From owner-freebsd-fs@FreeBSD.ORG Mon May 21 03:55:52 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 8001616A400 for ; Mon, 21 May 2007 03:55:52 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh2.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9AB13C4AE for ; Mon, 21 May 2007 03:55:52 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.centtech.com (andersonbox1.centtech.com [192.168.42.21]) by mh2.centtech.com (8.13.8/8.13.8) with ESMTP id l4L3tlVR070845; Sun, 20 May 2007 22:55:48 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46511843.4010205@freebsd.org> Date: Sun, 20 May 2007 22:55:47 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.0 (X11/20070420) 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-Virus-Scanned: ClamAV 0.88.4/3272/Sun May 20 20:06:25 2007 on mh2.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=8.0 tests=AWL, BAYES_05, WHILE_YOU_SLEEP autolearn=no version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh2.centtech.com 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: Mon, 21 May 2007 03:55:52 -0000 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