Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Sep 2003 21:04:37 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        "Marc G. Fournier" <scrappy@hub.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Improvements to fsck performance in -current ...? 
Message-ID:  <Pine.NEB.3.96L.1030930210113.7344I-100000@fledge.watson.org>
In-Reply-To: <20030930194544.H94686@ganymede.hub.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Tue, 30 Sep 2003, Marc G. Fournier wrote:

> > Current has two major changes re speeding up fsck.
> >
> > The most significant is the background operation of fsck on file system
> > with soft updates enabled. Because of the way softupdates works, you are
> > assured of metadata consistency on reboot, so the file systems can be
> > mounted and used immediately with fsck started up in the background
> > about a minute after the system comes up.
> 
> Actually, I had this blow up on my -CURRENT desktop once ... didn't have
> a clue on how to debug it, so I switched from fsck -p to fsck -y to
> prevent it from happening again :(

No idea when this happened to you, but background fsck/snapshots have
become dramatically more stable since about half way between 5.0-release
and 5.1-release.  Kirk chased down a lot of serious bugs and issues with
hangs.  So experience from before that time may not be characteristic of
current behavior. 

> Now,I don't/wouldn't have softupdates enabled on / .. does the
> 'background fsck' know to not background if softupdates are not enabled? 
> I'm going to switch back to -p and look a bit closer the next time it
> happens (if it happens) to see if it is/was a softupdate file system
> that failed, now that I have a better idea of what I'm looking for ... 

sysinstall doesn't enable soft updates on / by default, as for small
partitions you increase the chance of running into space concerns.  Many
of the space concerns have been resolved by some more recent behavioral
changes in UFS.  The issue in question is that soft updates trickles out
changes in a write-behind, and in the event of a large delete followed by
an immediate large allocation, the deleted storage may not have been
reclaimed when the allocation comes along.  For example, if you had a
really small / and did an installkernel.  In more recent 5.x, UFS now
tracks the space that "will be freed" and reports it as freed, and
includes some support for waiting for space to become available (which it
inevitably will in that situation, once the soft updates have been
processed).

So the picture may have improved a lot since you last used it, depending
on when that was.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030930210113.7344I-100000>