Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 May 2004 12:39:54 -0500
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Scott Long <scottl@freebsd.org>
Cc:        Michael Hamburg <hamburg@fas.harvard.edu>
Subject:   Re: fsck in -current
Message-ID:  <20040516173954.GB80376@dan.emsphone.com>
In-Reply-To: <40A7A143.7070907@freebsd.org>
References:  <20040515220258.H920@ganymede.hub.org> <D3AE316C-A6D9-11D8-89DA-0003939A19AA@fas.harvard.edu> <20040515233728.Q30269@ganymede.hub.org> <FA17DF77-A6FB-11D8-89DA-0003939A19AA@fas.harvard.edu> <20040516163039.GE29158@dan.emsphone.com> <40A79A54.3090703@freebsd.org> <20040516170441.GA80376@dan.emsphone.com> <40A7A143.7070907@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (May 16), Scott Long said:
> Dan Nelson wrote:
> >In the last episode (May 16), Scott Long said:
> >
> >>Actually, bgfsck unconditionally inserts a delay into every 8th i/o
> >>operation to try to keep from saturating the disks.  Unfortunately
> >>this isn't terribly sophisticated and it results in bgfsck taking
> >>an eternity whether the system is idle, loaded, or reniced.
> >
> >See http://dan.allantgroup.com/FreeBSD/fsck_ffs.diff for a patch
> >that removes the delay if it's at the minimum value, and more fairly
> >calculates disk wait time.  This cuts bgfsck time from ~4 hours to
> >20 minutes on my 36gb /usr.
> 
> Looks like a reasonable fix.  Do you want it reviewed and committed?

Sure.  I don't remember why I bumped up the max wait time to 2.5 sec,
though.  That's probably too long.

-- 
	Dan Nelson
	dnelson@allantgroup.com



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