Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Scoopta <mlist@scoopta.email>, linux-btrfs@vger.kernel.org
Subject: Re: Safety of raid1 vs raid10
Date: Tue, 10 Dec 2024 15:06:25 +1030	[thread overview]
Message-ID: <74c8536a-3108-4e6c-941a-5d7b9c697862@suse.com> (raw)
In-Reply-To: <a7f1781b-6ae8-4e71-ba00-6c1c11c4901d@scoopta.email>



在 2024/12/10 12:56, Scoopta 写道:
> 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.

It's only theoretically possible, but hardly possible in the real world.


For one single RAID10 chunk, btrfs can tolerant as many as half of the 
devices being missing, as long as each sub stripe (the RAID1 pair) has 
one device standing.

E.g. for chunk at bytenr X, we have 4 stripes:

  stripe 0 devid 1 physical X1
  stripe 1 devid 2 physical X2
  stripe 2 devid 3 physical X3
  stripe 3 devid 4 physical X4

We can have either devid 1+3 or devid 2+4 missing, and btrfs is totally 
fine with that chunk.

But the real problem is, one btrfs has more than 3 chunks, and normally 
one chunk is only 1GiB in size, so for a btrfs with 1TiB used space, it 
will have at least 1024 chunks.

Good luck all the chunks have the same stripe layout.

If there is another chunk at bytenr Y, also 4 stripes but a different 
layout:

  stripe 0 devid 1 physical Y1
  stripe 1 devid 3 physical Y2
  stripe 2 devid 2 physical Y3
  stripe 3 devid 4 physical Y4

Then the devid 1+3 missing is fine for chunk X, but not for chunk Y.

In really, the chunk layout is never ensured, and I just did the same 
RAID10 assumption in my btrfs-fuse project, until it failed selftest 
(missing two devices for a RAID10 btrfs) on a recent kernel, exactly due 
to the device rotation.

Thanks,
Qu

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

  parent reply	other threads:[~2024-12-10  4:36 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
2024-12-10  4:36 ` Qu Wenruo [this message]
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=74c8536a-3108-4e6c-941a-5d7b9c697862@suse.com \
    --to=wqu@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mlist@scoopta.email \
    /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