RAID 1 vs RAID 0

RAID 1 vs RAID 0

[Max Waterman]

Hi,

I've been reading a bit about RAID 1 vs RAID 0 on these pages :

<http://www.pcguide.com/ref/hdd/perf/raid/levels/single_Level1.htm>

They seem to suggest RAID 0 is faster for reading than RAID 1, and I 
can't figure out why.

Clearly, the write performance is worse for RAID 1 than RAID 0 since 
with RAID 1 that data you are writing at the same time is the same for 
both drives; but for reading, why can't the two drives be read as if 
they were a stripe.

You could even read the stripe in any 'direction'...when the RAID 1 
array has more than two disks, that would make RAID 1 *faster* than RAID 0.

ie

RAID 0
file is like this
0 1 2 3 4

can only be read in that order :
0 1 2 3 4 but

RAID 1
file is like this
A B C D E
---------
0 0 0 0 0
1 1 1 1 1
2 2 2 2 2
3 3 3 3 3
4 4 4 4 4

can be read as
A B C D E
0
   1
     2
       3
         4

or
1
   0
     3
       4
         2

or whatever...

Could it not help with small files and when not streaming?

Am I missing something?

Max.

Re: RAID 1 vs RAID 0

[Max Waterman]

Ah, it's something to with RAID1 drives having to skip blocks that are 
read from the other drives, right?

i.e., it's about the head having to move further, instead of to just the 
next block? I suppose that's only important for sequential reads, and it 
would be 'fixed' to some extent by the drives' cache...

Max.

Max Waterman wrote:
> Hi,
> 
> I've been reading a bit about RAID 1 vs RAID 0 on these pages :
> 
> <http://www.pcguide.com/ref/hdd/perf/raid/levels/single_Level1.htm>
> 
> They seem to suggest RAID 0 is faster for reading than RAID 1, and I 
> can't figure out why.
> 
> Clearly, the write performance is worse for RAID 1 than RAID 0 since 
> with RAID 1 that data you are writing at the same time is the same for 
> both drives; but for reading, why can't the two drives be read as if 
> they were a stripe.
> 
> You could even read the stripe in any 'direction'...when the RAID 1 
> array has more than two disks, that would make RAID 1 *faster* than RAID 0.
> 
> ie
> 
> RAID 0
> file is like this
> 0 1 2 3 4
> 
> can only be read in that order :
> 0 1 2 3 4 but
> 
> RAID 1
> file is like this
> A B C D E
> ---------
> 0 0 0 0 0
> 1 1 1 1 1
> 2 2 2 2 2
> 3 3 3 3 3
> 4 4 4 4 4
> 
> can be read as
> A B C D E
> 0
>   1
>     2
>       3
>         4
> 
> or
> 1
>   0
>     3
>       4
>         2
> 
> or whatever...
> 
> Could it not help with small files and when not streaming?
> 
> Am I missing something?
> 
> Max.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: RAID 1 vs RAID 0

[Mark Hahn]

> They seem to suggest RAID 0 is faster for reading than RAID 1, and I 
> can't figure out why.

with R0, streaming from two disks involves no seeks;
with R1, a single stream will have to read, say 0-64K from the first disk,
and 64-128K from the second.  these could happen at the same time, and 
would indeed match R0 bandwidth.  but with R1, each disk has to seek past
the blocks being read from the other disk.  seeking tends to be slow...

> Clearly, the write performance is worse for RAID 1 than RAID 0 since 
> with RAID 1 that data you are writing at the same time is the same for 
> both drives;

the cost for doing the double writes in R1 is not high, unless you've 
already got a bottleneck somewhere that limits you to talking to one disk
at a time.  for instance, R1 to a pair of disks at 50 MB/s apiece is 
basically trivial for a decent server, since it's about 1% of memory
bandwidth, and a smallish fraction of even plain old 64x66 PCI.

> array has more than two disks, that would make RAID 1 *faster* than RAID 0.

R1 is not going to be faster than R0 on the same number of disks.

regards, mark hahn.

Re: RAID 1 vs RAID 0

[Max Waterman]

Mark Hahn wrote:
>> They seem to suggest RAID 0 is faster for reading than RAID 1, and I 
>> can't figure out why.
> 
> with R0, streaming from two disks involves no seeks;
> with R1, a single stream will have to read, say 0-64K from the first disk,
> and 64-128K from the second.  these could happen at the same time, and 
> would indeed match R0 bandwidth.  but with R1, each disk has to seek past
> the blocks being read from the other disk.  seeking tends to be slow...

Ah, a good way of putting it...I think I was pretty much there with my 
followup message.

Still, it seems like it should be a solvable problem...if you order the 
data differently on each disk; for example, in the two disk case, 
putting odd and even numbered 'stripes' on different platters [or sides 
of platters].

> 
>> Clearly, the write performance is worse for RAID 1 than RAID 0 since 
>> with RAID 1 that data you are writing at the same time is the same for 
>> both drives;
> 
> the cost for doing the double writes in R1 is not high, unless you've 
> already got a bottleneck somewhere that limits you to talking to one disk
> at a time.  for instance, R1 to a pair of disks at 50 MB/s apiece is 
> basically trivial for a decent server, since it's about 1% of memory
> bandwidth, and a smallish fraction of even plain old 64x66 PCI.
> 
>> array has more than two disks, that would make RAID 1 *faster* than RAID 0.
> 
> R1 is not going to be faster than R0 on the same number of disks.

Yeah, I think I see that now.

Thanks.

Max.

> 
> regards, mark hahn.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: RAID 1 vs RAID 0

[Brad Campbell]

Max Waterman wrote:
> 
> Still, it seems like it should be a solvable problem...if you order the 
> data differently on each disk; for example, in the two disk case, 
> putting odd and even numbered 'stripes' on different platters [or sides 
> of platters].
> 

The only problem there is determining the internal geometry of the disk, and knowing that each disk 
is probably different. How do you know which logical sector number correlates to which surface and 
where abouts on the surface? Just thinking about it makes my brain hurt.

Not like the good old days of the old stepper disks.

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: RAID 1 vs RAID 0

[Mario 'BitKoenig' Holbe]

Max Waterman <davidmaxwaterman+gmane@fastmail.co.uk> wrote:
> Still, it seems like it should be a solvable problem...if you order the 
> data differently on each disk; for example, in the two disk case, 
> putting odd and even numbered 'stripes' on different platters [or sides 

Well, unfortunately for todays hard disks the OS doesn't know anything
anymore about platters, cylinders, sectors, zones etc.
Furthermore, such an attempt would break the (really nice!) ability to
use each single RAID1 mirror as a plain blockdevice with a plain
filesystem on it.


regards
   Mario
-- 
It is a capital mistake to theorize before one has data.
Insensibly one begins to twist facts to suit theories instead of theories
to suit facts.                   -- Sherlock Holmes by Arthur Conan Doyle

Re: RAID 1 vs RAID 0

[Neil Brown]

On Wednesday January 18, davidmaxwaterman+gmane@fastmail.co.uk wrote:
> Mark Hahn wrote:
> >> They seem to suggest RAID 0 is faster for reading than RAID 1, and I 
> >> can't figure out why.
> > 
> > with R0, streaming from two disks involves no seeks;
> > with R1, a single stream will have to read, say 0-64K from the first disk,
> > and 64-128K from the second.  these could happen at the same time, and 
> > would indeed match R0 bandwidth.  but with R1, each disk has to seek past
> > the blocks being read from the other disk.  seeking tends to be slow...
> 
> Ah, a good way of putting it...I think I was pretty much there with my 
> followup message.
> 
> Still, it seems like it should be a solvable problem...if you order the 
> data differently on each disk; for example, in the two disk case, 
> putting odd and even numbered 'stripes' on different platters [or sides 
> of platters].

raid10 'far' mode is exactly designed to address this issue.
If you create a raid10 with 2 drives and a layout of 'f2':

  mdadm -C /dev/mdX --level=10 --layout=f2 --raid-disks=2 /dev/XX /dev/YY

then reads should be comparable to a raid0 of 2 drives, but you still
get raid1 protections.
Writes may be substantially slower though I haven't measured to be
sure.

It doesn't do "different sides of platters" as that is not possible
with modern drives (you have no knowledge and no control).  It does
different 'ends' of the drive.

NeilBrown

Re: RAID 1 vs RAID 0

[John Hendrikx]

Max Waterman wrote:
> Mark Hahn wrote:
>>> They seem to suggest RAID 0 is faster for reading than RAID 1, and I 
>>> can't figure out why.
>>
>> with R0, streaming from two disks involves no seeks;
>> with R1, a single stream will have to read, say 0-64K from the first 
>> disk,
>> and 64-128K from the second.  these could happen at the same time, 
>> and would indeed match R0 bandwidth.  but with R1, each disk has to 
>> seek past
>> the blocks being read from the other disk.  seeking tends to be slow...
>
> Ah, a good way of putting it...I think I was pretty much there with my 
> followup message.
>
> Still, it seems like it should be a solvable problem...if you order 
> the data differently on each disk; for example, in the two disk case, 
> putting odd and even numbered 'stripes' on different platters [or 
> sides of platters].
I don't think the example above is really that much of an issue.  AFAIK, 
most hard disks will read the current track (all platters) at once as 
soon as the heads are positioned.  It doesn't even wait for the start of 
the track, it just starts reading as soon as possible and stores all of 
it in the internal buffer (it will determine the real start of the track 
by looking for markers in the buffer).  It will then return the data 
from the buffer.

Anyway, the track buffer is quite large because it needs to be able to 
hold the data from an entire track, which is usually quite a bit larger 
than the stripe size (I'd say around 1 to 2 MB).  It's highly unlikely 
that your hard disk will need to seek to read 0-64k, then 128-192k, then 
256-320k, and so on.  There's a good chance that all of that data is 
stored on the same track and can be returned directly from the buffer.  
Even if a seek is required, it would only be a seek of 1 track which are 
relatively fast compared to a random seek.

The only reason I could think of why a mirror would be slower than a 
stripe is the fact that about twice as many single track seeks are 
needed when reading huge files.  That can be avoided if you increase the 
size of the reads significantly though (for example, reading the 1st 
half of the file from one disk, and the 2nd half of the file from the 
other).

--John