Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 May 2004 10:44:04 -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:  <40A79A54.3090703@freebsd.org>
In-Reply-To: <20040516163039.GE29158@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>

next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote:
> In the last episode (May 16), Michael Hamburg said:
> 
>>On May 15, 2004, at 10:41 PM, 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.
> 
> 
> Fsck takes very little CPU; it's almost all disk I/O, and bgfsck tries
> to throttle its load if it thinks that there's too much disk load.
> 

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.

A _really_ nice TODO item for FreeBSD 6.0 would be a real I/O scheduler.
There are plenty of papers on it, some even focused on FreeBSD.  Any
volunteers?

Scott



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