Re: Benefits from computing physical IDE disk geometry?

[Nick Piggin <piggin@cyberone.com.au>]

Timothy Miller wrote:

>I'm excited about the new I/O scheduler (proposed?) in the 2.5.x kernel, but
>I have to admit to a considerable amount of ignorance of its actual
>behavior.  Thus, if it already does what I'm talking about, please feel free
>to ignore this post.  :)
>
>
>Any good SCSI drive knows the physical geometry of the disk and can
>therefore optimally schedule reads and writes.  Although necessary features,
>like read queueing, are also available in the current SATA spec, I'm not
>sure most drives will implement it, at least not very well.
>
The "continuous" nature of drive addressing means that the kernel
can do a fine job seek-wise. Due to write caches and read track
buffers, rotational scheduling (which could be done if we knew
geometry) would provide too little gain for the complexity. I would
say that for most workloads you wouldn't see any difference. (IMO)

>
>
>So, what if one were to write a program which would perform a bunch of
>seek-time tests to estimate an IDE disk's physical geometry?
>
Yes, something like this has been done.

>It could then
>make that information available to the kernel to use to reorder accesses
>more optimally.  Additionally, discrepancies from expected seek times could
>be logged in the kernel and used to further improve efficiency over time.
>
The benefit I see is knowing the seek time itself (not geometry), which
can be used to tune the IO scheduler. This is something that I'll
probably need to do (in kernel) in order to get my IO scheduler in 2.6,
as it probably (not tested yet) has bad failure cases on high seek time
devices like CDROMs.

>
>If it were good enough, many of the advantages of using SCSI disks would
>become less significant.
>
I'm not sure that this is among SCSI's big advantages. I know some
SCSI disks have farness/starvation problems with big reorder windows.

>
>
>Ideas?
>
It is worth looking into I think. I will be testing something like it
for AS but in kernel not userspace. I don't think it would be very
useful to help basic head movement optimization, but I would like
someone else to prove me wrong.