From owner-freebsd-current@FreeBSD.ORG Mon May 17 07:27:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4F1D16A4CE for ; Mon, 17 May 2004 07:27:10 -0700 (PDT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4E2E443D39 for ; Mon, 17 May 2004 07:27:09 -0700 (PDT) (envelope-from ltning@anduin.net) Received: (qmail 82269 invoked by uid 6759); 17 May 2004 14:27:02 -0000 Received: from ltning@anduin.net by anduin.net by uid 82 with qmail-scanner-1.20 (clamscan: 0.60. spamassassin: 2.60. Clear:RC:1(217.8.136.185):. Processed in 0.027849 secs); 17 May 2004 14:27:02 -0000 X-Qmail-Scanner-Mail-From: ltning@anduin.net via anduin.net X-Qmail-Scanner: 1.20 (Clear:RC:1(217.8.136.185):. Processed in 0.027849 secs) Received: from gatekeeper.in-space.org (HELO ?192.168.1.10?) (217.8.136.185) by anduin.net with SMTP; 17 May 2004 14:27:02 -0000 Message-ID: <40A8CB9E.2000400@anduin.net> Date: Mon, 17 May 2004 16:26:38 +0200 From: Eirik Oeverby User-Agent: Mozilla Thunderbird 0.6 (X11/20040504) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: freebsd-current@freebsd.org References: <20040515220258.H920@ganymede.hub.org> <20040515233728.Q30269@ganymede.hub.org> <20040516163039.GE29158@dan.emsphone.com> <40A79A54.3090703@freebsd.org> In-Reply-To: <40A79A54.3090703@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: fsck in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 14:27:11 -0000 Funny, was thinking about that the other day. Not that I could do anything - I'm not a developer on that scale at all. Was just thinking about how worthless SCHED_ULE and SCHED_4BSD are in cases of massive I/O, and why a scheduler doesn't handle those things too. Then I thought some more about it, and complications and difficulties popped up every way I turned. I wouldn't be surprised if noone volunteers ;) But seriously, what project size would we be talking about here? Did any other OSes implement anything like it? Would it be a 'killer feature'? /Eirik Scott Long wrote: > 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 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"