[lkml]   [1998]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: elevator algorithm bug in ll_rw_blk.c
On 16-Nov-98 H. Peter Anvin wrote:
>> > 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.

i take it that you were joking

this sucker runs on quad xeons and ultrasparcs and gazillion buses and fj massivly
parallel sparcs and nasa clusters and finding out the geometry of a disk is

"beyond our knowledge"

what is the slowest part of linux (hark, i can hear larry limbering up at the back
of the auditorium)
i would be most surprised if it wasn't disk accesses - just physically getting the
blocks on and off the disk

anything which speeded that out by a pico second is going to pay dividends all
around. on this list people talk about shaving a nano seconds off secheduling and
what have you. getting the data on to and off the disk is measured in milliseconds.

"beyond our knowledge"

i bet if some disk manufacturer (are you listening quantum, seagate, ibm, maxtor)
realised they could gain just a small increase in market share by being a bit more
linux friendly with disk geometry - they would be banging on the doors (who's door
mind you is another matter)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:45    [W:0.078 / U:2.776 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site