why can't RAID 1 perform like RAID 0?

V

venm11

2[H]4U
Joined
Oct 6, 2004
Messages
2,236
it seems to me that for long read operations, the controller could read simultaneously from alternating stripes on different drives, for the same operation, thus multiplying your read bandwidth like R0. Thats in addition to the existing R1 capability to handle different reads on different drives simultaneously (ie, R0+1 versus R1+0).

Do any do this, like those wacky nonstandard raid levels?
 
I'm a bit confused with what you mean and are asking.

RAID1 = Mirrored drives (2 drives) Benefit = redundancy, speed of one, data is duplicated on both drives, if one fails replace it to gain redundancy again.
RAID0 = Striped drives (2+ drives, equal numbers) Benefit = speed of both, no redundancy, total loss if s drive fails.
RAID10 = Mirrored Striped drives (4+ drives, equal numbers) a.k.a. RAID0+1, Benefit = speed of both mirrors striped like RAID0 while keeping redundancy.

RAID1 cant perform like RAID0 because you only get the performance of a single drive. When using RAID1, just pretend you only have 1 drive because it's for redundancy, not performance. If you want the benefits of both you naturally need RAID10 (0+1). A good hardware controller never hurts either.
 
MikeTrike said:
RAID1 cant perform like RAID0 because you only get the performance of a single drive. When using RAID1, just pretend you only have 1 drive because it's for redundancy, not performance.
Click to expand...

For writes this is true. For reads, it's possible to stripe because the data is the same on both disks, so you can simultaneously read different blocks from each disk.

I'm not aware of any controllers that actually do this. For hardware RAID it's probably tricky to implement since it's only aware of a single block per request, so no easy way to detect which reads are random and which are streaming, and the penalty incurred in seeking the head to start a striped read is probably not worth it when most RAID controllers are optimized for IOPS, not streaming throughput.
 
Now I understand what you meant, and to answer I have no idea. :(

Kinda threw me off there, the idea sounds good on paper though.
 
I don't have any proof of this, but I suspect R1 can't double your bandwidth by reading alternate stripes from each drive because the drives would have to seek between each stripe, wasting the time they could otherwise just be reading sequential data. The hard drives are spinning at a fixed speed, so skipping a sector means the drive waits for the next stripe to rotate into place rather than being able to skip directly ahead to it. I think the implementation you have in mind might be possible on an SSD, but not on anything with spinning platters.
 
keenan said:
I'm not aware of any controllers that actually do this. For hardware RAID it's probably tricky to implement
Click to expand...
Steve01S4 said:
I don't have any proof of this, but I suspect R1 can't double your bandwidth by reading alternate stripes from each drive because the drives would have to seek between each stripe, wasting the time they could otherwise just be reading sequential data.
Click to expand...


TwinStor's been around for 11 years...

http://www.3ware.com/products/pdf/raid_primer.pdf
http://www.3ware.com/products/pdf/twinstor.pdf
 
Tolyngee said:
TwinStor's been around for 11 years...
Click to expand...

Yes, twinstor looks exactly like what I was thinking. With ebay prices for some fo these, 64 bits and true raid offloading, this might be a winner.

john4200 said:
mdadm (linux software RAID) can do something like what you are asking
Click to expand...

Its' very confusing though. As best I understand it, this is like stripes at the beginning of the disk, with mirrors on the latter half of the disk (A1 B2 ... A2.. B1). I'm guessing the inner parity stripes are written asynchronously, which would have performance benefits (considering that your stripe set is short-stroked) as well as greater risks of failure from parity not being written simultaneously. And performance during a drive failure would drop so much that a hot rebuild might be out of the question. Does this sound correct?
 
venm11 said:
Its' very confusing though. As best I understand it, this is like stripes at the beginning of the disk, with mirrors on the latter half of the disk (A1 B2 ... A2.. B1). I'm guessing the inner parity stripes are written asynchronously, which would have performance benefits (considering that your stripe set is short-stroked) as well as greater risks of failure from parity not being written simultaneously. And performance during a drive failure would drop so much that a hot rebuild might be out of the question. Does this sound correct?
Click to expand...

Disk X Disk Y

Raid 0: A B
Raid 1: A A-M
Raid1e: A/B-M B/A-M

1e basically handles any number of disks greater than 1 and provides short stroked raid 0 performance for reads with ~Raid 1 performance for writes (esp with a BBWC).
 
Last edited:
Yeah I read the thread title and twinstore piped in my mind but it is important to mention that about every decent raid chipset does this now, twinstore is just a 3ware feature name. You can't really speed up writes on a raid 1 though, just reads.
 
MaxBurn said:
Yeah I read the thread title and twinstore piped in my mind but it is important to mention that about every decent raid chipset does this now, twinstore is just a 3ware feature name. You can't really speed up writes on a raid 1 though, just reads.
Click to expand...

I'd imagine that hardware raid implementations do, but it seems like a lot of logic for say.. an entry level or consumer raid chip. I haven't seen any other chipsets claim to do that... certainly not any consumer-grade stuff.
 
Linux mdadm RAID1 does balance reads across disks. While a single read operation is always conducted by one disk, multiple distinct reads, for example from different threads or applications can be carried out by different disks. I think this is a better solution than striping reads, because a striping approach will only increase throughput, while this can decrease average access times.
 
You must log in or register to reply here.
Back
Top