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