Date: Sun, 16 May 2004 01:43:37 -0400 From: Michael Hamburg <hamburg@fas.harvard.edu> To: freebsd-current@freebsd.org Subject: Re: fsck in -current Message-ID: <FA17DF77-A6FB-11D8-89DA-0003939A19AA@fas.harvard.edu> In-Reply-To: <20040515233728.Q30269@ganymede.hub.org> References: <20040515220258.H920@ganymede.hub.org> <D3AE316C-A6D9-11D8-89DA-0003939A19AA@fas.harvard.edu> <20040515233728.Q30269@ganymede.hub.org>
index | next in thread | previous in thread | raw e-mail
On May 15, 2004, at 10:41 PM, Marc G. Fournier wrote: > On Sat, 15 May 2004, Michael Hamburg wrote: > >> On May 15, 2004, at 9:08 PM, Marc G. Fournier wrote: >> >>> >>> I'm seriously considering putting 5.x onto my next server, to take >>> advantage of, if nothing else, the reduction in the GIANT LOCK >>> reliance >>> ... one "concern" I have is how fsck works in 5.x ... >>> >>> Right now, on 4.x, I have an fsck running that has been going for >>> ~3hrs >>> now: >>> >>> # date; ps aux | grep fsck >>> Sat May 15 22:04:00 ADT 2004 >>> root 40 99.0 4.5 185756 185796 p0 R+ 6:55PM 164:01.60 fsck >>> -y >>> /dev/da0s1h >>> >>> and is in Phase 4 ... >>> >>> In 5.x, if I'm not mistaken, fsck's are backgrounded on reboot, so >>> that >>> the system comes up faster ... but: >>> >>> a. wouldn't that slow down the fsck itself, since all the processes >>> on >>> the >>> machine would be using CPU/memory? >> >> Yes. You can probably renice it or something, though, and it wouldn't >> take that much longer. >> >> Furthermore, if I recall correctly, it doesn't check as much after a >> crash when soft-updates are enabled. See below. >> >>> b. how long could fsck run in the background safely ... like, if I >>> rebooted a machine, fsck backgrounded and then all the processes >>> started up, is there a risk involved? >>> >> >> No, fsck should be able to run in the background indefinitely with >> basically no risk, so long as you have free space on your disk. The >> way that the latest fsck works is that it snapshots the drive, and >> then >> checks the snapshot; the only type of error that it's expecting to >> find >> is files which have been deleted but whose space has not been >> reclaimed. This space can be recovered without confusing running >> processes. > > 'k ... fsck just started spewing messages to the screen, which is nice > cause now I know its actually doing something: > > ZERO LENGTH DIR I=5159669 OWNER=root MODE=40755 > SIZE=0 MTIME=May 10 17:32 2004 > CLEAR? yes > > now, the ZERO LENGTH DIR is a result of using unionfs ... but would > that > cause any issues with the snapshotting? like, how much 'free space' > would > you need, and what happens ifyou don't have enough? :( > I don't know about ZERO LENGTH DIRs... I've never had to deal with anything terribly interesting in an interactive fsck. You don't need much space unless you have high turnover -- the default extra space in FFS that you can't allocate anyway should be plenty, but as far as I can tell, if you do run out of space, Very Bad Things Happen (tm). Just what those Very Bad Things are probably depends on the release. Mikehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FA17DF77-A6FB-11D8-89DA-0003939A19AA>