Messages in this thread | | | From | (H. Peter Anvin) | Subject | Re: elevator algorithm bug in ll_rw_blk.c | Date | 16 Nov 1998 12:15:33 GMT |
| |
Followup to: <199811160539.XAA19590@dyheli.kwr> By author: kwrohrer@ce.mediaone.net In newsgroup: linux.dev.kernel > > The cylinder/head/sector numbers have been lies for years. With a SCSI > disk you could read the true geometries, including sectors per track in > each of the various zones, together with the defect map and know exactly > where each block lies on the disk...but the angular position of the disc > is a whopping 11 ms variable (5400 RPM), and you can't optimize for it > in the OS without guessing at it, then hoping you aren't interrupted > too badly before acting on that guess. >
Actually u could measure the position once, measure the rate of rotation and then just correlate to the system clock... of course doesn't work for ZBR disks :)
> > i think it was rsx-11 which used to format the disk to take into account > > retational delays > I've seen DOS floppy formatting programs that do that. Meanwhile, since > hard disk makers have been bragging about sustained transfer rate for the > past several years, I can guarantee they've skewed the tracks properly to > optimize sequential reads across track boundaries...and not even a SCSI > drive will tell you the value of this skew, AFAIK...
Yes, these kinds of optimizations are useful, and beyond our knowledge.
-hpa -- PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74 See http://www.zytor.com/~hpa/ for web page and full PGP public key I am Bahá'í -- ask me about it or see http://www.bahai.org/ "To love another person is to see the face of God." -- Les Misérables
- 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/
| |