disk scheduling (was: Re: RFC: adding 'proxy' nodes to provider ports (with patch))

[Poul-Henning Kamp]

In message <eb21ef440903211800h266ec0aes158cb189095289c1 at mail.gmail.com>, Luigi
 Rizzo writes:

>The thread was meant to be on inserting transparent nodes in GEOM.
>
>Scheduling was just an example on where the problem came out, 

Scheduling is the *only* application I have seen mentioned for
this special case geom construct ?

>+ nobody objects that the ideal place for scheduling is where
>  requests naturally "pile up". Too bad that this ideal
>  place is sometimes one we cannot access, i.e. the firmware
>  of the disk drive.

Do you seriously propose that we could compete in scheduling
quality, with the disk drives firmware on drives that can have
multiple outstanding requests ?

>+ [anticipatory scheduling]
>  As such you can implement them effectively even above the device driver.

I have yet to see any study propose that they could do any good
inside the geom mesh, as opposed to right in front of the device
driver ?

>+ changing disksort can do some things but not all one would want.
>  [...]

Then the correct answer is to insert a perfectly normal geom
class above the disk drive to implement that.  I totally fail
to se what special kind of classes would buy you ?

>if you want a quick example [...]

I know what anticipatory disk-scheduling is, what it does,
and what the downsides of it are. (I also know that with
SSD's it becomes all but pointless).

The question is not if we should improve disksorting, the question
is if we need to hack up GEOM for it.

The answer is "no".

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.