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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
