Benefits from computing physical IDE disk geometry?

Benefits from computing physical IDE disk geometry?

[Timothy Miller]

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.

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?  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.
If it were good enough, many of the advantages of using SCSI disks would
become less significant.

Ideas?

AW: Benefits from computing physical IDE disk geometry?

[Oliver S.]

> Any good SCSI drive knows the physical geometry of the disk and can
> therefore optimally schedule reads and writes.

 If the scheduler inside the OS can rely on the drive to have a linear
mapping it is implemented as a cyclical-scan scheduler, there is only
a little difference in the effectivity of the scheduling.

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

 AFAIK the Seagate Barracudas implement first-party-dma, which is a
very lightweight implementation of command-queuing; with first-party
-dma, the CPU includes the adresses of where the data for a certain
request is read or written into the request-command so that when the
disk responds to a command, it sends this information back to the
controller. So this chip doesn't have to hold a list of outstanding
requests and their scattered adresses where the data is read from or
written to. Doesn't look very elegant, but that's just in line with
the cheap ATA-concepts.
 And the only controller-chips I'm aware of supporting this features
are the chips fom Silicon Image. But I think that sooner or later,
all SATA-chips will support it.

Re: Benefits from computing physical IDE disk geometry?

[John Bradford]

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

On a system that's been set up with one large root partition, and
nothing else, you might get a noticable gain, but I would guess that
you could get a simliar gain by partitioning the disk and manually
placing, E.G. /var near the outside of the disk, and things like /etc
near the centre.  I.E. placing more active partitions on faster areas
of the disk.

> If it were good enough, many of the advantages of using SCSI disks would
> become less significant.

Not really - there are still a lot of advantages of SCSI that it
wouldn't address.

John.

Re: Benefits from computing physical IDE disk geometry?

[Nick Piggin]

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.

Re: Benefits from computing physical IDE disk geometry?

[Timothy Miller]

From: "Nick Piggin" <piggin@cyberone.com.au>


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

Well, that IS the heart of the matter, really.  Detecting geometry was only
a means to the end of predicting seek time and rotational latency.  If you
could magically predict the seek time between any two accesses, then you
could sort your queue optimally.  What would be able to do that?  A neural
net?  :)  What would be able to do that without a lot of training time?

Personally, I've been excited about AS, and I would hate to see it not get
in.

Re: Benefits from computing physical IDE disk geometry?

[Nick Piggin]

Timothy Miller wrote:

>From: "Nick Piggin" <piggin@cyberone.com.au>
>
>
>>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.
>>
>
>Well, that IS the heart of the matter, really.  Detecting geometry was only
>a means to the end of predicting seek time and rotational latency.
>
OK yeah. I thought you had more exotic techniques in mind
like rotational latency optimisation which require actual geometry

>  If you
>could magically predict the seek time between any two accesses, then you
>could sort your queue optimally.
>
Well using the assumption that |head sector - target sector| gives
an ordering correstponding to seek time, we do sort the queue optimally.
I personally feel that being trickier than that is too much complexity.

>What would be able to do that?  A neural
>net?  :)  What would be able to do that without a lot of training time?
>
I think just some averages, maybe histograms. Not quite sure exactly
how I'll need to do it. I probably want each IO submitting process'
average seek time, and the average seek time when changing from one
process to another. Nothing too fancy.

>
>
>Personally, I've been excited about AS, and I would hate to see it not get
>in.
>
It is getting there. It definitely does some things much better than
deadline, although in other areas it is not so good.

Re: Benefits from computing physical IDE disk geometry?

[Mark Hahn]

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

but seek time is some combination of headswitch time, rotational 
latency, and actual head motion.  the first three are basically
not accessible in any practical way.  the latter is easy, and the 
current approximation (seek time is a linear function of block distance)
is very reasonable.

adjusting the cost function would be interesting: I'm guessing that 
handling short seeks (which are quite fast) would be more important
than adjusting for zones.  given that the current queueing code 
handles starvation, I wonder if we could actually permit backward
seeks of, say, 0-2 cylinders.

> Well using the assumption that |head sector - target sector| gives
> an ordering correstponding to seek time, we do sort the queue optimally.
> I personally feel that being trickier than that is too much complexity.

exactly.

Re: Benefits from computing physical IDE disk geometry?

[Nick Piggin]

Mark Hahn wrote:

>>>>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
>>>>
>
>but seek time is some combination of headswitch time, rotational 
>latency, and actual head motion.  the first three are basically
>not accessible in any practical way.  the latter is easy, and the 
>
Yep which is one reason why I don't think being fancy will pay
off (the other reason being that even if you did know the parameters
I don't think they would help a lot).

I just want to know the average seek time.

>
>current approximation (seek time is a linear function of block distance)
>is very reasonable.
>
Well, strictly, not linear. But yes it does provide a good ordering.
That is besides the point though: I can decide if one request will
have a shorter seek time than another just fine. I would still like
to know the aproximate seek _time_ for higher level tuning stuff
eg. will anticipation be worth it, and how soon should requests
expire.

>
>
>adjusting the cost function would be interesting: I'm guessing that 
>handling short seeks (which are quite fast) would be more important
>than adjusting for zones.  given that the current queueing code 
>handles starvation, I wonder if we could actually permit backward
>seeks of, say, 0-2 cylinders.
>
There is (in AS) no cost function further than comparing distance
from the head. Closest forward seek wins.

If by the queueing code you mean the actual IO schedulers? Then
yes, they do handle starvation, however they (AS, deadline)
handle _fairness_ by not seeking backward. Well actually
AS does allow a process to seek upto IIRC 256MB backward
which is a couple of ext2 blockgroups while maintaining quite
good fairness.

>
>
>>Well using the assumption that |head sector - target sector| gives
>>an ordering correstponding to seek time, we do sort the queue optimally.
>>I personally feel that being trickier than that is too much complexity.
>>
>
>exactly.
>  
>

Re: Benefits from computing physical IDE disk geometry?

[Alan Cox]

On Sad, 2003-04-12 at 23:46, Timothy Miller wrote:
> 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.

Some of them are in recent PATA and Jens Axboe implemented the TCQ for
IDE, but its all a bit limited right now

> 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?  It could then
> make that information available to the kernel to use to reorder accesses
> more optimally.

Its a common misconception that a disk looks something like it did 15
years ago. Your ATA disk is basically an entire standalone computer 
running a small OS. The physical disk layout does not divide neatly 
into equal sized cylinders and some blocks may even be in suprising
places due to bad block sparing or anything else the drive manufacturer
felt appropriate.

The drive firmware will look after a lot of the optimising for you,
and once it gets TCQ it will probably get you all you want from SCSI
with SATA. Until then playing games with it isnt likely to help - feed
IDE disks large, sequential I/O as much as possible and they'll deliver
you very nice numbers. 

Alan

Re: Benefits from computing physical IDE disk geometry?

[John Bradford]

> > 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?  It could then
> > make that information available to the kernel to use to reorder accesses
> > more optimally.
> 
> Its a common misconception that a disk looks something like it did 15
> years ago. Your ATA disk is basically an entire standalone computer 
> running a small OS. The physical disk layout does not divide neatly 
> into equal sized cylinders and some blocks may even be in suprising
> places due to bad block sparing or anything else the drive manufacturer
> felt appropriate.

Is the basic assumption that lower block numbers are generally located
in zones nearer the outside of the disk still true, though?  I.E. do
you know of any disks that 'start from the middle'?  I usually
recommend that people place their swap and /var partitions near the
beginning of the disk, (for a _slight_ improvement), but maybe there
is a good reason not to do this for some disks?

John.

Re: Benefits from computing physical IDE disk geometry?

[Helge Hafting]

On Sun, Apr 13, 2003 at 05:15:51PM +0100, John Bradford wrote:
> Is the basic assumption that lower block numbers are generally located
> in zones nearer the outside of the disk still true, though?  I.E. do
> you know of any disks that 'start from the middle'?  I usually
> recommend that people place their swap and /var partitions near the
> beginning of the disk, (for a _slight_ improvement), but maybe there
> is a good reason not to do this for some disks?

I generally put swap in the middle of the disk, not on the
"fastest" end.  The "fast" end is faster for large transfers,
but that isn't what swap is about.

Swap tends to have lots of small transfers now and then, in between
other io.  So you want a short seek from wherever the
access arm is to keep latency down, and the middle of the
disk has short way both from inner and outer tracks.

Helge Hafting

Re: Benefits from computing physical IDE disk geometry?

[John Bradford]

> > Is the basic assumption that lower block numbers are generally located
> > in zones nearer the outside of the disk still true, though?  I.E. do
> > you know of any disks that 'start from the middle'?  I usually
> > recommend that people place their swap and /var partitions near the
> > beginning of the disk, (for a _slight_ improvement), but maybe there
> > is a good reason not to do this for some disks?
> 
> I generally put swap in the middle of the disk, not on the
> "fastest" end.  The "fast" end is faster for large transfers,
> but that isn't what swap is about.

Well, I was thinking of machines that are really starved of physical
RAM, 32 MB or less, even down to 4 MB.  I generally run swapless on
'real' machines :-).

Also, the higher capcity tracks mean less seeks, so the chance of not
having to seek at all increases slightly.

> Swap tends to have lots of small transfers now and then, in between
> other io.  So you want a short seek from wherever the
> access arm is to keep latency down, and the middle of the
> disk has short way both from inner and outer tracks.

Yeah, that would probably be a better idea for machines which are only
really hitting swap on occasions, instead of all the time :-).

John.

Re: Benefits from computing physical IDE disk geometry?

[Wes Felter]

On Sat, 2003-04-12 at 17:46, Timothy Miller wrote:

> 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?  It could then
> make that information available to the kernel to use to reorder accesses
> more optimally.

Greg Ganger et al. have done some recent work in this area:

http://www.pdl.cmu.edu/PDL-FTP/stray/freeblocks_abs.html
http://www.pdl.cmu.edu/PDL-FTP/stray/traxtent_abs.html

-- 
Wes Felter - wesley@felter.org - http://felter.org/wesley/