Date: Sun, 16 May 2004 11:45:15 -0600 From: Scott Long <scottl@freebsd.org> To: Dan Nelson <dnelson@allantgroup.com> Cc: Michael Hamburg <hamburg@fas.harvard.edu> Subject: Re: fsck in -current Message-ID: <40A7A8AB.2000707@freebsd.org> In-Reply-To: <20040516173954.GB80376@dan.emsphone.com> 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> <20040516173954.GB80376@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > 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. > Maybe you were seeing effects of the syncer daemon? It can easily generate 2+ seconds of i/o on a flush. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40A7A8AB.2000707>