From owner-freebsd-fs@FreeBSD.ORG Mon May 21 12:46:48 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 E630616A46B for ; Mon, 21 May 2007 12:46:48 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id B317013C44B for ; Mon, 21 May 2007 12:46:48 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.centtech.com (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l4LCkl71070833; Mon, 21 May 2007 07:46:48 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <465194B7.6070807@freebsd.org> Date: Mon, 21 May 2007 07:46:47 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.0 (X11/20070420) MIME-Version: 1.0 To: Scott Long References: <653845.99663.qm@web63012.mail.re1.yahoo.com> <46511843.4010205@freebsd.org> <46511F74.4090303@samsco.org> In-Reply-To: <46511F74.4090303@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/3273/Mon May 21 00:31:50 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=8.0 tests=AWL, BAYES_00, WHILE_YOU_SLEEP autolearn=no version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com 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 12:46:49 -0000 On 05/20/07 23:26, Scott Long wrote: > 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. Yea, from what I read though, it sounded like he just wanted to sleep without having to watch fsck's run. :) Eric