>>> I've got two different ide-disks in my system:
>>> /dev/hda --> 6,4GB SAMSUNG SV0644A 11.90 MB/sec
>>> /dev/hdb --> 13.2GB WDC WD136BA 22.22 MB/sec
> First i would suggest that you put each disk to separate
> channel. hdb --> hdc.
Absolutely and definately 100%, do that.
It thought it, got distracted by some user problem, and when I cam back to my
reply, I'd forgotten that the disks were mentioned by bus, and *ASSUMED*
they'd be on differnt controllers.
The standing orders I have with my suppliers are to put the IDE devices in
decreasing speed on: PM, SM, SS and PS (i.e. hda, hdc, hdd, hdb).
They seem to keep `forgetting' and go back to PM, PS, SM, SS :-(
When asked, why the two permanantly used, fast, striped HDAs were sharing one
controller, while the other controller only had one VERY rarely used, slow DVD
I was told that it `had to' bve like that, as if there was a non UDMA device on
a controller, then that controller could not use UDMA (e.g. like LVD vs SE).
I asked for more info, but (surprise, surprise) they had not hard facts.
I suggested that thay meant `under M$, if ...', and they agreed ... sigh :-(
So yes -- I have always built systems like that, based on theory ...
>> There are patches out there to make RAID1 reads into RAID0 reads -- you *may*
> I don't exactly know what you mean by making RAID1 reads into RAID0 reads.
Sorry -- I think it may be called `Balanced RAID1 reads' ...
When writing, the data has to to be written to both disks.
This means that the code issues // seek requests, does // writes, and it's done
when the last (second) write completes.
When reading, the data can be taken from either disk.
In particular, when there is a single disk client, reading serially through a
large file, the `best' way to do it might be to read chunks from each disk
alternately, making it look somewhat like RAID0, and double the throughput.
When I was HACKing the RAID code (some while ago now) this was not done, but
there was a comment in the kernel saying `this code should balance the reads'
or some such.
However, I think that in reality, the code needs to be a bit smarter ...
With multiple disk clients and an efficient FS, it would probably be better
to `halve' the number of seeks by using one disk to read the data from one file
(which will all be on the same cylinder [or so the hope is!], so no need for
any seeks betwwen reads) while the other disk is used to read all the blocks
from the other file ....
> Do you mean RAID 10 configuration by this ?
I must admit I've never actually seen a definition of RAID10 -- I have always
taken it as a shorthand for `RAID 1 and RAID 0', i.e. resilient striped.
As such, I suspect not.
> Could you provide links to those patches ?
If you don't understand what I meant, I suspect I could trawl back through
the archives ... :-(
>> be able to get them, and tweak them so that it knows to actually read 1/3rd
>> of the data off the slow disk, and 2/3rds off the fast disk ... Fun !!
> I would say that the overall performance gain would be noticeable and
> worthwhile, even without this kind of weighted read balancer.
Sure, but being able to auto-tune for the observed speed of the disks would be
even better than straight alternation ...
> Ofcourse the other disk is twice as slow what comes to
> throughput performance, but it certainly is not twice as slow
> when it comes to seek speeds. Prolly just 20-30%
Again, it boils down to locality of reference.
If doing a number of sucessive reads from a single cylinder, and then seeking,
the seek cost is reduced.
`the norm' is that a `slow' disk has a small capacity, slow seek times, slow
transfer rates, and low recording density.
`small capacity' typically means `fewer heads', so smaller cylinders, so more
seeks needed. `low recording density' means that there are fewer sectors per
track, so fewer sectors per cylinder, so more seeking.
> So in effect he would gain almost double amount of seeks / sec,
It stands some chance of speeding up reads too ...
If it was reading from the `fast' disk all the time, then balancing will not
help (raw reading) as half the data will come from the fast disk (in half the
time it took to read it all from the fast disk), but the other half will take
just as long as reading it all from the fast disk (as it is half the speed).
However, the other case is a winner -- if it was using the slow disk,
half the data will arrive in 1/4 the time, and the other half in half the time,
so the overall speed is halved. (it's just that if 2/3rds was from the fast
disk, it could be done in 1/rd the time).
> which would greatly improve overall io performance. Typically accesses to
> disk in 'normal' usage are scattered, sometimes even if you read a
> single file sequentially.
I kind of hope that the underlying FS will optimise for locality of reference
for a single fle (and even related files !).
Cylinders are reasonably large things on modern disks ...
If only we were back in the days when the kernel knew the *physical* layout on
disk, we could have all those heads reading at once, getting a whole cylinder
per revolutions (1/7200s) ... :-))
> you can say that your io is as much seeking as it is reading/writing.
I'd noit quite go that far, but yes, seeking is significant and slow.
> In other words io performance is function of both
> throughput and seeks and you should keep _both_ in mind.
AGREED !!!!
> What i would like to see more in this list is that when folks
> submit their performance figures, instead of just putting MB/sec
> there would be seeks/sec also =)
I wish that hdparm had a `random seek' flag to cause it to read `random' block
rather than linear ones.
bonnie is way too complex and slow for such things, needs an expert to drive it
and neeeds large free disk space -- with 1GB of RAM, it needs a fair chunk of
disk to scribble on ...
> That would allow us to see the strenghts and weaknesses of different raid
> systems more accurately and thus we could select the correct setup to our
> specific need.
Tweak hdparm ...
> Briefly: seeks _DO_ matter :)
Agreed.
