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. I've read that the snapshot code is safe for fsck and dump, but can still deadlock if you try to mount a snapshot or shut down with a snapshot present, but the document dates from two years ago. Is this still true? > ---- > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) > Email: scrappy_at_hub.org Yahoo!: yscrappy ICQ: > 7615664 Mike HamburgReceived on Sat May 15 2004 - 16:39:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:54 UTC