Date: Mon, 21 May 2007 07:46:47 -0500 From: Eric Anderson <anderson@freebsd.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-fs@freebsd.org, Gore Jarold <gore_jarold@yahoo.com> Subject: Re: dangers of delaying an fsck on busy fileserver ? Message-ID: <465194B7.6070807@freebsd.org> In-Reply-To: <46511F74.4090303@samsco.org> References: <653845.99663.qm@web63012.mail.re1.yahoo.com> <46511843.4010205@freebsd.org> <46511F74.4090303@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/20/07 23:26, Scott Long wrote: > Eric Anderson wrote: >> On 05/20/07 15:28, Gore Jarold wrote: >>> --- Scott Long <scottl@samsco.org> wrote: >>> >>>> Gore Jarold wrote: >>>>> --- Scott Long <scottl@samsco.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?465194B7.6070807>