All of lore.kernel.org
 help / color / mirror / Atom feed
From: "George Shammas" <btrfs@shamm.as>
To: "Chris Murphy" <lists@colorremedies.com>,
	"Phillip Susi" <phill@thesusis.net>
Cc: "Btrfs BTRFS" <linux-btrfs@vger.kernel.org>
Subject: Re: What exactly is BTRFS Raid 10?
Date: Fri, 19 Aug 2022 18:37:46 -0400	[thread overview]
Message-ID: <6b835970-07c9-4b8c-a686-57776f494db8@www.fastmail.com> (raw)
In-Reply-To: <1a102e00-144c-43c8-bb08-7bdb4072d056@www.fastmail.com>



On Fri, Aug 19, 2022, at 6:18 PM, Chris Murphy wrote:
> man mkfs.btrfs explains some of this. Minimum devices 2.

My first mail included a link the the man page of mkfs.btrfs. It is devoid of information of raid10 other than it is an option.

> And keep in mind all btrfs raid is at the chunk level. Not block device 
> level. So there's no such thing as a mirrored device, but rather 
> mirrored chunks (two copies of a block group on separate block devices).
>
> And yes, you can only lose one device with btrfs raid10. 

And this is exactly why I am asking this question. Given that 
- both raid1 and raid10 can only tolerate a single disk failure
- chucks are placed evenly across drives, effectively making files striped even if the chucks themselves are not striped. 

It seems that both "raid1" and "raid10" are functionally equivalent in btrfs. Or there is a nuance that I'm missing and is not documented. 

These gotchas are not obvious to me, even after 12 years of working with traditional raid setups. 

Perhaps raid1 does not require that chucks are placed evenly, allowing for hotspots? In which case raid10 is almost always preferable unless you have disks of unequal size?

There needs to be some authoritative text on the differences and pros/cons  btrfs raid1 and btrfs raid10, especially since raid5/6 are not recommended.

--George

  reply	other threads:[~2022-08-19 22:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19 16:49 What exactly is BTRFS Raid 10? George Shammas
2022-08-19 18:10 ` Phillip Susi
2022-08-19 22:01   ` George Shammas
2022-08-19 22:18     ` Chris Murphy
2022-08-19 22:37       ` George Shammas [this message]
2022-08-19 22:29     ` waxhead
2022-08-22 19:51     ` Phillip Susi
2022-08-20 11:28 ` Goffredo Baroncelli
2022-08-20 18:11   ` Andrei Borzenkov
2022-08-21  0:23     ` Qu Wenruo

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=6b835970-07c9-4b8c-a686-57776f494db8@www.fastmail.com \
    --to=btrfs@shamm.as \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=phill@thesusis.net \
    /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.