From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Scoopta <mlist@scoopta.email>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Safety of raid1 vs raid10
Date: Tue, 10 Dec 2024 00:12:06 -0500 [thread overview]
Message-ID: <Z1fNpnKlKgE2gh69@hungrycats.org> (raw)
In-Reply-To: <c86d8af9-4b26-4917-9ef3-de38003ee365@scoopta.email>
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.
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.
>
next prev parent reply other threads:[~2024-12-10 5:12 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 [this message]
2024-12-10 5:45 ` Scoopta
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=Z1fNpnKlKgE2gh69@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--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