Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Scoopta <mlist@scoopta.email>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Safety of raid1 vs raid10
Date: Mon, 9 Dec 2024 21:45:07 -0800	[thread overview]
Message-ID: <dff986e4-74c2-439f-af01-2bed827b33a4@scoopta.email> (raw)
In-Reply-To: <Z1fNpnKlKgE2gh69@hungrycats.org>

On 12/9/24 9:12 PM, Zygo Blaxell wrote:

> On Mon, Dec 09, 2024 at 06:44:14PM -0800, Scoopta wrote:
>> Ok, this is what I thought but I have seen so many articles that imply
>> raid10 groups drives and I have found no evidence for that. I was always
>> under the impression that neither raid 1 nor 10 grouped drives together
>> intentionally and any grouping was circumstantial.
> In traditional, non-btrfs raid1/raid10 setups, this can easily be the
> case, and people might be assuming this is also true on btrfs without
> checking.

Yeah I figured that's where the misconception was coming from but I 
wanted to verify that it was a misconception. It didn't make sense to me 
that btrfs would pair up raid10 drives but not raid1 drives. I figured 
they'd all behave the same way and that btrfs was free to organize data 
however it wanted provided the redundancy "on the tin", so to speak, was 
met.


> Traditional setups are much less flexible on space--you can't have
> different sizes of drives--but you can organize the drives such that
> each of them is entirely mirroring one other drive.  This can tolerate
> up to N/2 failures, as long as each failure only removes one drive from
> each pair--but it can also fail completely with only 2 drive failures,
> if they're both mirrors of the same stripe.
>
>> On 12/9/24 6:42 PM, Zygo Blaxell wrote:
>>> On Mon, Dec 09, 2024 at 06:26:24PM -0800, Scoopta wrote:
>>>> I've read online that btrfs raid10 is theoretically safer than raid1 because
>>>> raid10 groups drives together into mirrored pairs making the filesystem more
>>>> likely to successfully survive a multi-drive failure event. I can't find any
>>>> documentation that says this to be the case. Is it true that btrfs pairs
>>>> drives together for raid10 but not raid1, if this is the case what's the
>>>> reasoning for it?
>>> It is _possible_ for raid10 and raid1 to be arranged such that multiple drive
>>> losses are possible.  e.g. if all odd numbered devices are paired with all
>>> even numbered devices, then any odd numbered device can be lost and the
>>> filesystem still survives.
>>>
>>> This is not _guaranteed_, it is only _possible_.
>>>
>>> In a filesystem with an odd number of drives, or with drives of varying
>>> sizes, the block groups will only guarantee that one drive loss can be
>>> tolerated in each block group, in order to have the flexibility needed
>>> to fill all available space.  In such cases it is common that block
>>> groups are arranged in such a way that loss of any two drives will break
>>> the filesystem.

  reply	other threads:[~2024-12-10  5:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-10  2:26 Safety of raid1 vs raid10 Scoopta
2024-12-10  2:42 ` Zygo Blaxell
2024-12-10  2:44   ` Scoopta
2024-12-10  5:12     ` Zygo Blaxell
2024-12-10  5:45       ` Scoopta [this message]
2024-12-10  4:36 ` Qu Wenruo
2024-12-10  6:36   ` Scoopta
2024-12-10  7:54     ` Qu Wenruo
2024-12-10 17:01       ` Scoopta

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=dff986e4-74c2-439f-af01-2bed827b33a4@scoopta.email \
    --to=mlist@scoopta.email \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox