From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>,
Anand Jain <anand.jain@oracle.com>,
btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: About minimal device number for RAID5/6
Date: Tue, 16 Aug 2016 08:01:07 -0400 [thread overview]
Message-ID: <a995f4fc-0c42-d346-07e3-9d764d2bf9e9@gmail.com> (raw)
In-Reply-To: <e2b165ec-4a82-6550-82d0-46352a32c3b8@cn.fujitsu.com>
On 2016-08-15 21:32, Qu Wenruo wrote:
>
>
> At 08/15/2016 10:10 PM, Austin S. Hemmelgarn wrote:
>> On 2016-08-15 10:08, Anand Jain wrote:
>>>
>>>
>>>>> IMHO it's better to warn user about 2 devices RAID5 or 3 devices
>>>>> RAID6.
>>>>>
>>>>> Any comment is welcomed.
>>>>>
>>>> Based on looking at the code, we do in fact support 2/3 devices for
>>>> raid5/6 respectively.
>>>>
>>>> Personally, I agree that we should warn when trying to do this, but I
>>>> absolutely don't think we should stop it from happening.
>>>
>>>
>>> How does 2 disks RAID5 work ?
>> One disk is your data, the other is your parity. In essence, it works
>> like a really computationally expensive version of RAID1 with 2 disks,
>> which is why it's considered a degenerate configuration.
>
> I totally agree with the fact that 2 disk raid5 is just a slow raid1.
>
>> Three disks in
>> RAID6 is similar, but has a slight advantage at the moment in BTRFS
>> because it's the only way to configure three disks so you can lose two
>> and not lose any data as we have no support for higher order replication
>> than 2 copies yet.
>
> It's true that btrfs doesn't support any other raid level which can
> provide 2 parities.
>
> But the use case to gain the ability to lose 2 disks in a 3 disk raid6
> setup seems more like a trick other than normal use case.
It absolutely is a trick, but until we have support for more than 2
copies in raid1 mode, it is also an absolutely legitimate use case.
>
> Either in mkfs man page, or warning at mkfs time (but still allowing to
> do it), IMHO it's better to tell user "yes, you can do it, but it's not
> a really good idea"
Agreed.
next prev parent reply other threads:[~2016-08-16 12:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-15 7:50 About minimal device number for RAID5/6 Qu Wenruo
2016-08-15 11:57 ` Austin S. Hemmelgarn
2016-08-15 14:08 ` Anand Jain
2016-08-15 14:10 ` Austin S. Hemmelgarn
2016-08-15 14:32 ` Anand Jain
2016-08-15 15:01 ` Austin S. Hemmelgarn
2016-08-15 18:30 ` Hugo Mills
2016-08-15 21:20 ` Henk Slager
2016-08-16 1:32 ` Qu Wenruo
2016-08-16 12:01 ` Austin S. Hemmelgarn [this message]
2016-08-15 13:58 ` Anand Jain
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=a995f4fc-0c42-d346-07e3-9d764d2bf9e9@gmail.com \
--to=ahferroin7@gmail.com \
--cc=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).