This is a discussion on Re: Pluggable Disk Scheduler Project - FreeBSD ; On tir, okt 16, 2007 at 04:10:37 +0200, Karsten Behrmann wrote: > > Hi, > > is anybody working on the `Pluggable Disk Scheduler Project' from > > the ideas page? > I've been kicking the idea around in my ...
On tir, okt 16, 2007 at 04:10:37 +0200, Karsten Behrmann wrote:
> > Hi,
> > is anybody working on the `Pluggable Disk Scheduler Project' from
> > the ideas page?
> I've been kicking the idea around in my head, but I'm probably newer to
> everything involved than you are, so feel free to pick it up. If you want,
> we can toss some ideas and code to each other, though I don't really
> have anything on the latter.
> > After reading ,  and its follow-ups the main problems that
> > need to be addressed seem to be:
> > o is working on disk scheduling worth at all?
> Probably, one of the main applications would be to make the background
> fsck a little more well-behaved.
I agree, as I said before, the ability to give I/O priorities is probably one
of the most important things.
> > o Where is the right place (in GEOM) for a disk scheduler?
> > o How can anticipation be introduced into the GEOM framework?
> I wouldn't focus on just anticipation, but also other types of
> schedulers (I/O scheduling influenced by nice value?)
> > o What can be an interface for disk schedulers?
> good question, but geom seems a good start
> > o How to deal with devices that handle multiple request per time?
> Bad news first: this is most disks out there, in a way
> SCSI has tagged queuing, ATA has native command queing or
> whatever the ata people came up over their morning coffee today.
> I'll mention a bit more about this further down.
> > o How to deal with metadata requests and other VFS issues?
> Like any other disk request, though for priority-respecting
> schedulers this may get rather interesting.
> > The main idea is to allow the scheduler to enqueue the requests
> > having only one (other small fixed numbers can be better on some
> > hardware) outstanding request and to pass new requests to its
> > provider only after the service of the previous one ended.
> - servers where anticipatory performs better than elevator
> - realtime environments that need a scheduler fitting their needs
> - the background fsck, if someone implements a "priority" scheduler
Apache is actally a good candidate according to the old antipacitory design
document ( not sure of it's relevance today, but...)
Over to a more general view of it's architecture:
When I looked at this project for the first time, I was under the impression
that this would be best done in a GEOM class.
However, I think the approach that was taken in the Hybrid project is better
because of the following reasons:
- It makes it possible to use by _both_ GEOM classes and device drivers (Which
might use some other scheduler type?).
- Does not remove any configuratbility, since changing etc. can be done by user
- Could make it possible for a GEOM class to decide for itself which scheduler it
wants to use (most GEOM classes uses the standard bioq_disksort interface in
- The ability to stack a GEOM class with a scheduler could easily be "emulated"
by creating a GEOM class to utilize the disksched framework.
All in all, I just think this approach gives more flexibility than putting it in
a GEOM class that have to be added manually by a user.
Just my thought on this.
Also, I got my test-box up again today, and will be trying your patch as soon
as I've upgraded it to CURRENT Fabio.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"