Re: Poor Software RAID-0 performance with 2.6.14.2

Re: Poor Software RAID-0 performance with 2.6.14.2

[Bill Davidsen]

Lars Roland wrote:
> I have created a stripe across two 500Gb disks located on separate IDE
> channels using:
> 
> mdadm -Cv /dev/md0 -c32 -n2 -l0 /dev/hdb /dev/hdd
> 
> the performance is awful on both kernel 2.6.12.5 and 2.6.14.2 (even
> with hdparm and blockdev tuning), both bonnie++ and hdparm (included
> below) shows a single disk operating faster than the stripe:

In looking at this I found something interesting, even though you 
identified your problem before I was able to use the data for the 
intended purpose. So other than suggesting that the stripe size is too 
small, nothing on that, your hardware is the issue.

I have two ATA drives connected, and each has two partitions. The first 
partition of each is mirrored for reliability with default 64k chunks, 
and the second is striped, with 512k chunks (I write a lot of 100MB 
files to this f/s).

Reading the individual devices with dd, I saw a transfer rate of about 
60MB/s, while the striped md1 device gave just under 120MB/s. (60.3573 
and 119.6458) actually. However, the mirrored md0 also gave just 60MB/s 
read speed.

One of the advantages of mirroring is that if there is heavy read load 
when one drive is busy there is another copy of the data on the other 
drive(s). But doing 1MB reads on the mirrored device did not show that 
the kernel took advantage of this in any way. In fact, it looks as if 
all the reads are going to the first device, even with multiple 
processes running. Does the md code now set "write-mostly" by default 
and only go to the redundant drives if the first fails?

I won't be able to do a lot of testing until Thursday, or perhaps 
Wednesday night, but that is not as I expected and not what I want, I do 
mirroring on web and news servers to spread the head motion, now I will 
be looking at the stats to see if that's happening.

I added the raid M/L to the addresses, since this is getting to be 
general RAID question.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Poor Software RAID-0 performance with 2.6.14.2

[Paul Clements]

Bill Davidsen wrote:

> One of the advantages of mirroring is that if there is heavy read load 
> when one drive is busy there is another copy of the data on the other 
> drive(s). But doing 1MB reads on the mirrored device did not show that 
> the kernel took advantage of this in any way. In fact, it looks as if 
> all the reads are going to the first device, even with multiple 
> processes running. Does the md code now set "write-mostly" by default 
> and only go to the redundant drives if the first fails?

No, it doesn't use write-mostly by default. The way raid1 read balancing 
works (in recent kernels) is this:

- sequential reads continue to go to the first disk

- for non-sequential reads, the code tries to pick the disk whose head 
is "closest" to the sector that needs to be read

So even if the reads aren't exactly sequential, you probably still end 
up reading from the first disk most of the time. I imagine with a more 
random read pattern you'd see the second disk getting used.

--
Paul

Re: Poor Software RAID-0 performance with 2.6.14.2

[Bill Davidsen]

Paul Clements wrote:
> Bill Davidsen wrote:
> 
>> One of the advantages of mirroring is that if there is heavy read load 
>> when one drive is busy there is another copy of the data on the other 
>> drive(s). But doing 1MB reads on the mirrored device did not show that 
>> the kernel took advantage of this in any way. In fact, it looks as if 
>> all the reads are going to the first device, even with multiple 
>> processes running. Does the md code now set "write-mostly" by default 
>> and only go to the redundant drives if the first fails?
> 
> 
> No, it doesn't use write-mostly by default. The way raid1 read balancing 
> works (in recent kernels) is this:
> 
> - sequential reads continue to go to the first disk
> 
> - for non-sequential reads, the code tries to pick the disk whose head 
> is "closest" to the sector that needs to be read
> 
> So even if the reads aren't exactly sequential, you probably still end 
> up reading from the first disk most of the time. I imagine with a more 
> random read pattern you'd see the second disk getting used.

Thanks for the clarification. I think the current method is best for 
most cases, I have to think about how large a file you would need to 
have any saving in transfer time given that you have to consider the 
slowest seek, drives doing other things on a busy system, etc.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me