fsck in -current

[Eirik Oeverby]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"