Re: fsck in -current

From: Brooks Davis <brooks_at_one-eyed-alien.net>
Date: Sat, 15 May 2004 21:08:28 -0700
On Sat, May 15, 2004 at 11:41:41PM -0300, 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? :(

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="NO".

-- Brooks

-- 
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

Received on Sat May 15 2004 - 19:08:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:54 UTC