Benefits from computing physical IDE disk geometry?
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?
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 10 lines
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.
Quoted 2 lines
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.
Quoted 11 lines · 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.
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)
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
From: "Nick Piggin" <[email protected]>
Quoted 5 lines
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.
Quoted 10 lines · Timothy Miller
From: "Nick Piggin" <[email protected]>
Quoted 6 lines
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.
Quoted 3 lines
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
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 7 lines · Mark Hahn
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 10 lines
Quoted 6 lines
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.
Quoted 4 lines · Timothy Miller
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
Quoted 4 lines
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
Quoted 11 lines
Quoted 4 lines
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.
Quoted 6 lines · 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.
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
Quoted 10 lines
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 4 lines · Timothy Miller
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
Signature · 1 line
Wes Felter - [email protected] - http://felter.org/wesley/