linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: ronnie sahlberg <ronniesahlberg@gmail.com>,
	Dave <davestechshop@gmail.com>
Cc: Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Parity-based redundancy (RAID5/6/triple parity and beyond) on BTRFS and MDADM (Dec 2014) – Ronny Egners Blog
Date: Thu, 2 Nov 2017 07:21:47 -0400	[thread overview]
Message-ID: <2560b19a-3a1d-6ea5-fd83-f5b154200b50@gmail.com> (raw)
In-Reply-To: <CAN05THRy7tnmY__obtgjkT76kKcR-_YWHcfDgdwLDf1A2qY0+w@mail.gmail.com>

On 2017-11-02 03:29, ronnie sahlberg wrote:
> I think it is just a matter of lack of resources.
> The very few paid resources to work on btrfs probably does not have
> priority to work on parity raid.
> (And honestly, parity raid is probably much better implemented below
> the filesystem in any case, i.e. in say the md driver or the array
> itself).
More specifically, they likely don't have incentive to work on higher 
order parity raid.  The common case for most of the paid developers 
companies is running large scale storage using BTRFS as a back-end.  In 
such a situation, it makes more sense to use smaller BTRFS volumes in 
raid5 or raid6 mode (or even raid1 or raid10), and handle striping at 
the cluster level instead of the node level.
> 
> Also, until at least about a year ago, RAID56 was known to be
> completely broken in btrfs and would destroy all your data.
> Not a question of when, but if.
> 
> So, considering the state of parity raid in btrfs it is understandable
> if the few resources available would not work on Andrea's 6 parity
> raid code.
> I don't follow the parity raid code in btrfs closely, it might be
> fixed by now or it might still be pathologically broken. I don't know.
> I assume it is still deadly to use btrfs raid5/6.
AFAIK, it's better than it was, but it's still broken.>
> That said, that the MDADM folks did not pick up on Andrea's work is a tragedy.
> While it is really just Reed-Solomon coding, his breakthrough was that
> he found a 6 parity Reed-Solomon encoding  where the first two
> parities
> were identical to the RAID5/6 parities.
> I.e. you could add a third parity to a normal RAID6 and thus create a
> 3-parity system without having to recompute the first and second
> parity.
> 
> 
> 
> 
> On Thu, Nov 2, 2017 at 12:45 PM, Dave <davestechshop@gmail.com> wrote:
>> Has this been discussed here? Has anything changed since it was written?
>>
>> Parity-based redundancy (RAID5/6/triple parity and beyond) on BTRFS
>> and MDADM (Dec 2014) – Ronny Egners Blog
>> http://blog.ronnyegner-consulting.de/2014/12/10/parity-based-redundancy-raid56triple-parity-and-beyond-on-btrfs-and-mdadm-dec-2014/comment-page-1/
>>
>> TL;DR: There are patches to extend the linux kernel to support up to 6
>> parity disks but BTRFS does not want them because it does not fit
>> their “business case” and MDADM would want them but somebody needs to
>> develop patches for the MDADM component. The kernel raid
>> implementation is ready and usable. If someone volunteers to do this
>> kind of work I would support with equipment and myself as a test
>> resource.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2017-11-02 11:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-02  2:45 Parity-based redundancy (RAID5/6/triple parity and beyond) on BTRFS and MDADM (Dec 2014) – Ronny Egners Blog Dave
2017-11-02  7:29 ` ronnie sahlberg
2017-11-02 11:21   ` Austin S. Hemmelgarn [this message]
2017-11-02 22:06 ` waxhead
2017-11-04  1:09   ` Chris Murphy
2017-11-05  6:52   ` Duncan

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=2560b19a-3a1d-6ea5-fd83-f5b154200b50@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=davestechshop@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=ronniesahlberg@gmail.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).