Messages in this thread | | | Date | 20 Mar 1999 23:40:00 +0200 | From | (Kai Henningsen) | Subject | Re: disk head scheduling |
| |
arvinds@mit.edu (Arvind Sankar) wrote on 19.03.99 in <19990319181823.A543@anjala.mit.edu>:
> On Fri, Mar 19, 1999 at 03:45:11PM -0500, Richard B. Johnson wrote:
> > A write splice occurs when you need to write some new sectors between > > existing sectors, i.e., you are not going to write an entire track. This > > often requires that the disc make up to one complete rotation before a > > write can begin because the drive has to "learn" where the starting sector > > is by reading sectors. Note, all sectors on hard disks are "soft" which > > means that there is no index to tell the electronics when to turn on the > > write current. If writes get queued together, and you have multiple > > writes, there is a chance some writes will occur on the same track. This > > means that since the drive already knows where the sectors are on that > > track, it doesn't have to reread. > > I don't get this. If this were true, then the average latency of a disk > would be the time for one complete rotation (half a rotation to find the > start, and half a rotation to actually get to the right place). But the > average latency is equal to _half_ the time for a complete rotation.
Nope.
I've written such software for floppies (way back when an Apple ][+ was a nice computer), and what I'd expect is half a rotation plus a little bit more. (Incidentally, that floppy driver already had ballistic head movement.)
Because that's how it works: scan the track until you know the next sector is the one you want, wait for the current sector to end (or the header of the next sector to occur, depending on what's actually written on the platter), then start writing.
You don't usually go looking for a different point on the track first. That's just a waste. (And that's why index holes are a bad idea.)
MfG Kai
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |