Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 May 2004 23:41:41 -0300 (ADT)
From:      "Marc G. Fournier" <scrappy@hub.org>
To:        Michael Hamburg <hamburg@fas.harvard.edu>
Cc:        freebsd-current@freebsd.org
Subject:   Re: fsck in -current 
Message-ID:  <20040515233728.Q30269@ganymede.hub.org>
In-Reply-To: <D3AE316C-A6D9-11D8-89DA-0003939A19AA@fas.harvard.edu>
References:  <20040515220258.H920@ganymede.hub.org> <D3AE316C-A6D9-11D8-89DA-0003939A19AA@fas.harvard.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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? :(

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040515233728.Q30269>