raid1 vs raid5

Hello all and excuse me if this is a silly question. I looked around in the wiki and list archives but couldn't find any in-depth discussion about this:

I just realized that, since raid1 in btrfs is special (meaning only two copies in different devices), the effect in terms of resilience achieved with raid1 and raid5 are the same: you can lose one drive and not lose data.

So!, presuming that raid5 were at the same level of maturity, what would be the pros/cons of each mode?

As a corollary, I guess that if raid1 is considered a good compromise, then functional equivalents to raid6 and beyond could simply be implemented as "storing n copies in different devices", dropping any complex parity computations and making this mode entirely generic. Since this seems pretty obvious, I'd welcome your insights on what are the things I'm missing, since it doesn't exist (and it isn't planned to be this way, AFAIK). I can foresee consistency difficulties, but that seems hardly insurmountable if its being done for raid1?

Thanks in advance,
Psalle.

This is true for "classic" RAID: assume you have 3x 1TB disks. RAID1 will give you 1.5TB, whereas RAID5 will give you 2TB.

RAID1 = 1/2 total disk space (assuming equally-sized disks) RAID5 = (N-1)*single disk space (same assumption)

This is akin to what has been mentioned on the list earlier as "N-way mirroring" and I agree that it will be very nice to have once implemented. However it is not the same as RAID5/6 since the parity schemes are used to get more usable storage than just simple mirroring would allow for.

Thus, the main pro of RAID5/6 is more usable storage, and the main con is more computational complexity (and thus more cpu requirements, slower access time, more fragile error states, etc.)

Fixing an inconsistency in RAID1 is much easier than RAID5/6. No math, just checking csums. Fixing an inconsistency in RAID5/6 involves busting out the parity math. This is why repairing RAID5/6 only became possible in btrfs relatively recently. Generating the parity data was relatively easy, but rebuilding missing data with it was a more difficult task.

--Sean

I had forgotten about this post and on rethinking about it I realized the kind of brain fart I was having. So thanks for the merciful silence ;-)