Pluggable Disk Schedulers in GEOM

[Poul-Henning Kamp]

In message <20070105015800.s3rqdzgm8k8owk4s at webmail.ntnu.no>, lulf at stud.ntnu.no
 writes:

>I was wondering if someone have started on the pluggable  
>disk-scheduler project
>on the "new ideas"-page yet.
>
>I was thinking on how one could implement this in GEOM by [...]

Sorting and scheduling should only be implemented at selected
points in the GEOM mesh and it can even be argued that it should
only be implemented at the bottom most level, right above the
physical storage media.

But given the increasing intelligence of disk drives in this
area, I would also caution against expecting too much of 
a gain in reality.

So before you embark on a major expedition, I would suggest
that you do some benchmarking and experiments with the
current disksorting, to shed light on the potential
for improvement.

Here are some ideas:

Remove disksorting and see if if and how big a difference
it makes today.  Test both SCSI, ATA and USB media, and
test both low-level benchmarks and "real-world" workloads.

Change disksorting to reverse unidirectional elevator
and bidirectional elevator and see if it makes a difference.
(Modern disks store blocks in reverse sector order on
the disk, discover and explain why)

Capture an I/O trace from a suitably sensible realworld
system, including the detailed timestamps of issuance
and completion of the requests.  Treat results statistically
and try to determine a formula for predicting how long
a given request is going to take for the disk.

It's not that I think that all your ideas are bad, I am just
not sure that the (traditional) view of the hardware they
are based on, is still relevant, and I think your time would
be much better spent addressing that question.

-- 
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.