Hard Drive Speed

[Konstantin Svist]

John Summerfield wrote:
> Konstantin Svist wrote:
>> John Summerfield wrote:
>>> Alan Cox wrote:
>>>
>>>>> * high-end HDs, e.g. 10,000+ RPM. These can improve your 
>>>>> performance somewhat, in the range of 10-20% - but it stacks on 
>>>>> top of performance gain of alternate filesystems. This is probably 
>>>>> the cheapest upgrade path.
>>>>
>>>> Also more but smaller disks. 8 40 GB disks have much better seek
>>>> behaviour than a single 320GB disk. They also take up a lot of room 
>>>> and
>>>> power 8(
>>>
>>>
>>> Have you tested that? It's not clear to me that that should be so. 
>>> Physical characteristics determine the number of platters that can 
>>> be in a drive, and you generally see a manufacturer release several 
>>> drives of different capacity at the same time.
>>>
>>> 3.5" drives have from one to (I think) five platters.
>>>
>>> At any moment, the five-platter version would have five times the 
>>> amount of data on they cylinder the heads are on compared with the 
>>> one-platter model.
>>>
>>> Seek times, when seeks are needed, would be the same. For many 
>>> applications, seeks would actually be needed less often.
>>>
>>>
>>> Comparisons between different models need to take into account the 
>>> bit density (which translates to the amount of data per track, and 
>>> the number of tracks per cylinder), and _all_ comparisons need to be 
>>> made comparing like areas of the recording surface. It used to be 
>>> the case that all tracks were the same size, but that's no longer 
>>> the case: tracks near the outer rim have more data than the short 
>>> ones near the centre.
>>>
>>> Unfortunately, the _real_ drive characteristics tend to be hidden; 
>>> the cylinders/tracks/sectors information on the labels is what DOS 
>>> might see. Even as far back as the 80s, some mainframe drives I knew 
>>> about reported physical characteristics to the OS (back then it was 
>>> MVS/XA) in terms of what the OS supported, and not the true 
>>> characteristics (on those drives, OS could not use the full capacity).
>>>
>>>
>>
>> I think what Alan had in mind was probably less about the physical 
>> characteristics of the drive(s) but more about the "random" aspect of 
>> random disk access. With lots of small drives, the load is 
>> distributed, so 2 seeks in a row on one drive (which add up) are run 
>> in parallel. In 
>
> And on the larger-capacity drive, if zero or one seek is needed? 
> Alan's assumptions depend on the physical characteristics of the 
> drives concerned, and it's not all that obvious.
>
>> other words, it's not a single-access performance improvement, but 
>> real-load improvement.
>> Thinking in terms of Squid, this makes perfect sense..
>
>
> I think I know fairly well what Alan had in mind, and it's something I 
> first heard raised in the mid-late 1970s, when Australia was first 
> implementing Medibank and we'd bought IBM's finest of the day, so it's 
> something I've had some time to consider.
>
> If Alan thinks I've misunderstood him, I'd like him to say so. He does 
> play with this stuff, he should understand my counterargument and be 
> able to make a sensible rebuttal, or agree with me.
>
>
>
sorry for butting in, i was just trying to be helpful :P