[geeks] recommended dual channel LVD controller, PC

[Björn Ramqvist]

Charles Shannon Hendrix wrote:

> Ah, I found it.  Much better.  I don't know how I missed that one.
> 
> Thanks.

It's easy to miss, done that a few times. :-)
No problem.

> Of course, now I find I need to play with my raid1 settings.  I'm
> getting 20MB/sec to the raid, but 21MB/sec to each drive alone.
> 
> I can read from both drives at the same time as high as 34MB/sec
> (40MB/sec bus maximum speed) so I figure I could tune this raid a little
> better.  It should get better read performance.

I've played very little with Linux MD in my days, I've only tested it 
ones when it was very new to the kernel and only the linear-option was 
stable.
I've done a few HW-raid setups at work, and in most cases you have to 
look at what size your writes are, and tune the stripe-sizes accordingly 
when you make up the raid. Databases suffer from many random I/Os, so 
there you want small stripes to spread the random seek across as many 
drives as you can. On day-to-day fileserving you can get away with 
bigger stripes to gain momentum in datatransfers with sequential I/Os.
It's a little bit of trial-and-error on this.

I don't know how Linux MD driver works, but atleast on our (smarter) 
HW-Raid engines at work, reading from a RAID-1 unit is striped in a 
RAID-0 fashion, since there are (hopefully?) the exact same data on both 
of the drives. Writing is ofcourse harder, since you loose half the 
datarate in writing the data twice, one on each drive. Some parallelism 
in writes can occur, but not very likely depending on what hardware you 
have and what I/O rates there is.

If slow writes is an issue, I'd place one mirror on each bus just to 
releave the bus of connecting/disconnecting and quite possibly to get 
some parallelism in the whole process of writing. Combine this with two 
striped disks on each channel, and mirroring the two stripes could 
reveal higher numbers. People here would probably go for the 
"striped-mirror" approach rather than the "mirrored-stripe" approach, 
since it's more tolerant to failures.
But then again, this is probably not a I/O intensive system. :-)

/Bjorn