All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Greenslade <sean@seangreenslade.com>
To: Psalle <psalleetsile@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: raid1 vs raid5
Date: Wed, 6 Jan 2016 03:09:08 -0500	[thread overview]
Message-ID: <20160106080907.GA30773@wheatley.ludlow.local> (raw)
In-Reply-To: <568BEE3F.4060402@gmail.com>

On Tue, Jan 05, 2016 at 05:24:31PM +0100, Psalle wrote:
> 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?

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)

> 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.

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.)

> 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?

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

  reply	other threads:[~2016-01-06  8:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-05 16:24 raid1 vs raid5 Psalle
2016-01-06  8:09 ` Sean Greenslade [this message]
2016-01-20 14:17 ` Psalle
  -- strict thread matches above, loose matches on Subject: below --
2003-10-26 14:45 RAID1 VS RAID5 Mario Giammarco
2003-10-26 16:16 ` maarten van den Berg
2003-10-26 18:22   ` Mario Giammarco
2003-10-27  8:27   ` Hermann Himmelbauer
2003-10-27  9:54     ` Lars Marowsky-Bree
2003-10-27 10:16     ` Jeff Woods
2003-10-28 10:45       ` Mario Giammarco
2003-10-27 11:08     ` maarten van den Berg
2003-10-27 12:03       ` Jeff Woods
2003-10-26 16:55 ` Matti Aarnio
2003-10-28 10:46   ` Mario Giammarco
2003-10-27  8:33 ` Hermann Himmelbauer
2003-10-27  9:19   ` Gordon Henderson
2003-10-27 11:01     ` Hermann Himmelbauer
2003-10-27 13:40       ` Gordon Henderson
2003-10-27 15:34         ` Hermann Himmelbauer
2003-10-27 14:17       ` Lars Marowsky-Bree
2003-10-27 15:52       ` Andrew Herdman
2003-10-28 10:40   ` Mario Giammarco
2003-10-26 11:24 Mario Giammarco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160106080907.GA30773@wheatley.ludlow.local \
    --to=sean@seangreenslade.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=psalleetsile@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.