maarten van den Berg wrote (in part):

The way it works now, AFAIK, is that concurrent read commands are issued 
to all the drives in Raid1.  Because of seek times and the amount of 
rotation needed to get the right sector underneath the head(s), one of the 
disks will be first to transfer the data. This can be 'sooner' by a large 
amount.

If you instead want to interleave reads you lose the possibility to gain 
speed from this mechanism described above. It would be a trade-off and I'm 
not sure interleaving would come out as the winner here.

IIUC, neither duplicate reads nor interleaved reads closely matches how 
(Linux software) RAID1 works.  I'm not sure what the local protocol is (and 
if I'm stepping way out of line here, someone please correct me offlist), 
but I'm going to quote another post sent via this listserver last month:

quoted

From: "Bailey, Scott" <redacted>
To: "'Andrew Herdman'" <redacted>
Cc: linux-raid@vger.kernel.org
Subject: RE: RAID1: Disks alternating on reads
Date: Tue, 23 Sep 2003 11:12:29 -0400

quoted

Pardon me if my assumption was incorrect, but I was under the belief 
that when using software RAID1, that when reads occurred on the RAID 
device that it would read from both drives in a striped fashion similar 
to how RAID0 works to improve the speed of the md devices.   I am 
actually seeing this, but it appears that the reads on each drive are 
continuing for 10 to 20 seconds before moving onto the next drive and 
then another 10-20 seconds and back again.  This is not allowing for any 
performance increase, it just lets the drives rest alternately.

My impression from crawling through the code a few months back was that 
this behavior was a design feature. On a read request, the request is 
sent to the device with heads "closest" to the target sector, EXCEPT that 
for sequential reads, the device gets reused on the assumption that the 
disk can be kept streaming, EXCEPT that after some maximum number of 
reads, another drive gets chosen to give the previous device a rest.

I speculate your files are contiguous (or nearly so) with the result that 
the initially closest drive gets hammered until its 'work quota' gets 
exceeded, and then the next drive will get pounded. And so on. To test 
this, I think you could reduce MAX_WORK_PER_DISK in raid1.c from the 
default 128 (in 2.4.21) to something smaller (perhaps 8 sectors for a 
filesystem with 4K block size?) and see if the load evens out.

Good luck,

        Scott Bailey
        scott.bailey at eds.com

I believe the method Scott says the present code uses to be near optimal 
and am skeptical that arbitrary changes to it would be improvements.  Of 
course, someone actually making such changes and then multiple people 
benchmarking it in a variety of different, well-designed, controlled tests 
is the only way to really tell.

--
Jeff Woods [off-list ref]