Re: Hard Drive Speed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 other words, it's not a single-access performance improvement, but real-load improvement.
Thinking in terms of Squid, this makes perfect sense..



--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux