A question on gmirror and "load sharing"

[Willem Jan Withagen]

[Remember it is considered bad etiquette to top post.
  trimming sigs and others is also a nice thing to do]

> Willem Jan Withagen wrote:
>> I'm in the proces of running some "performance" tests on raw disks, as 
>> a small   configuration test to run my NFS-perfomance tests on a 
>> different setup.
>>
>> (http://withagen.dyndns.org/FreeBSD/Performance)
>>
>> So I build a mirror with gmirror and 2 80Gb WD-sata disks.
>>
>> On that I run tests like (for reading):
>> ----
>> while ($i < 16000)
>>         dd of=/dev/null if=/dev/ad4 bs=5M count=1 iseek=$i
>> end
>> ----
>>
>> Giving me transfer times and rates that depend on the location of the 
>> head on the platter. The graphs seem to suggest that this simple test 
>> is not at all bad as an approach to this.
>> When you run this on an old BigFoot, which has a plexiglas view on the 
>> heads. You really see the arm creeping slowly to the spindle.
>>
>> However when I run this read test on a mirrored set of disks. I see 
>> (with systat -vm 1) that data is only transfered from 1 disk for a 
>> long time. And then several seconds later the other disk is used. This 
>> also happens if I create the mirror with 'gmirror label -b load'. And 
>> as such the transferrate of the mirror is equal or less than a single 
>> disk.
>>
>> Perhaps I should test this with 'split'?
>> Or is this something internal in the kernel that a 5Mb request comes 
>> in, and is forwarded as a whole request down the filesystem. And thus 
>> there is no parallellism to take advantage off. (Even on an SMP the 
>> request is to one disk only)

Tomas Zvala wrote:
 > Hello,
 > I did some similar testing and came to similar conclusion. As PJD
 > explained, the mirror will never double the transfer rate in sequential
 > I/O.
 > Here's the thread:
 > 
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+archive/2004/freebsd-geom/20041205.freebsd-geom 


Thanx for the pointer. Interesting to read.
And I'm now in the proces of testing the 'split' algorithm. And I have the 
feeling that I certain cases I do get above the speedmark equal to the 
transferrate of 1 disk.
But I'd have to agree with Pawel that in general seeking for 128K will be the 
same (or longer) than reading for 128K. Especially true when things are stored 
in the disk-cache, then perhaps a whole track is stored at once and the 
remainder is served from the cache.

--WjW