Date: Sat, 15 May 2004 21:08:28 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: "Marc G. Fournier" <scrappy@hub.org> Cc: Michael Hamburg <hamburg@fas.harvard.edu> Subject: Re: fsck in -current Message-ID: <20040516040828.GA17266@Odin.AC.HMC.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 15, 2004 at 11:41:41PM -0300, Marc G. Fournier wrote: > On Sat, 15 May 2004, Michael Hamburg wrote: >=20 > > 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 relian= ce > > > ... 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 ~3h= rs > > > 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 th= at > > > 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. >=20 > 'k ... fsck just started spewing messages to the screen, which is nice > cause now I know its actually doing something: >=20 > ZERO LENGTH DIR I=3D5159669 OWNER=3Droot MODE=3D40755 > SIZE=3D0 MTIME=3DMay 10 17:32 2004 > CLEAR? yes >=20 > 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? :( Very little. The snapshot just marks things so when they are modified later, a copy is made. Unless you are very short on space or you have a lot of turnover before the fsck finishes this isn't likely to be an issue. Basicly, you can't recover the space from any deletions until the fsck completes and modified files take up space as though they were new, but that's it. As long as you can accept that overhead, bgfsck should be OK. Of course, if you don't want it, you can always disable bgfsck in /etc/rc.conf with background_fsck=3D"NO". -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFApuk7XY6L6fI4GtQRAhL8AKDO+u2ThplOB9n9VQYvPQixiMmloQCeLqfY gIlPixdzIbVZ/7KDqX2eGMo= =AgZh -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040516040828.GA17266>