public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] OT: btrfs raid 5/6
Date: Sat, 9 Dec 2017 18:36:45 -0500	[thread overview]
Message-ID: <CAGfcS_nAaDVkT6v=_3cmhi_o90UFxF_YXg3O6GEDwLT-7QGozg@mail.gmail.com> (raw)
In-Reply-To: <5A2C2B44.6060802@youngman.org.uk>

On Sat, Dec 9, 2017 at 1:28 PM, Wols Lists <antlists@youngman.org.uk> wrote:
> On 09/12/17 16:58, J. Roeleveld wrote:
>> On Friday, December 8, 2017 12:48:45 AM CET Wols Lists wrote:
>>> On 07/12/17 22:35, Frank Steinmetzger wrote:
>>>>> (Oh - and md raid-5/6 also mix data and parity, so the same holds true
>>>>>
>>>>>> there.)
>>>>
>>>> Ok, wasn’t aware of that. I thought I read in a ZFS article that this were
>>>> a special thing.
>>>
>>> Say you've got a four-drive raid-6, it'll be something like
>>>
>>> data1   data2   parity1 parity2
>>> data3   parity3 parity4 data4
>>> parity5 parity6 data5   data6
>>>
>>> The only thing to watch out for (and zfs is likely the same) if a file
>>> fits inside a single chunk it will be recoverable from a single drive.
>>> And I think chunks can be anything up to 64MB.
>>
>> Except that ZFS doesn't have fixed on-disk-chunk-sizes. (especially if you use
>> compression)
>>
>> See:
>> https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
>>
> Which explains nothing, sorry ... :-(
>
> It goes on about 4K or 8K database blocks (and I'm talking about 64 MEG
> chunk sizes). And the OP was talking about files being recoverable from
> a disk that was removed from an array. Are you telling me that a *small*
> file has bits of it scattered across multiple drives? That would be *crazy*.

I'm not sure why it would be "crazy."  Granted, most parity RAID
systems seem to operate just as you describe, but I don't see why with
Reed Solomon you couldn't store ONLY parity data on all the drives.
All that matters is that you generate enough to recover the data - the
original data contains no more information than an equivalent number
of Reed-Solomon sets.  Of course, with the original data I imagine you
need to do less computation assuming you aren't bothering to check its
integrity against the parity data.

In case my point is clear a RAID would work perfectly fine if you had
5 drives with the capacity to store 4 drives wort of data, but instead
of storing the original data across 4 drives and having 1 of parity,
you instead compute 5 sets of parity so that now you have 9 sets of
data that can tolerate the loss of any 5, then throw away the sets
containing the original 4 sets of data and store the remaining 5 sets
of parity data across the 5 drives.  You can still tolerate the loss
of one more set, but all 4 of the original sets of data have been
tossed already.


-- 
Rich


  reply	other threads:[~2017-12-09 23:36 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 22:30 [gentoo-user] OT: btrfs raid 5/6 Bill Kenworthy
2017-12-01 15:59 ` J. Roeleveld
2017-12-01 16:58 ` Wols Lists
2017-12-01 17:14   ` Rich Freeman
2017-12-01 17:24     ` Wols Lists
2017-12-06 23:28     ` Frank Steinmetzger
2017-12-06 23:35       ` Rich Freeman
2017-12-07  0:13         ` Frank Steinmetzger
2017-12-07  0:29           ` Rich Freeman
2017-12-07 21:37             ` Frank Steinmetzger
2017-12-07 21:49               ` Wols Lists
2017-12-07 22:35                 ` Frank Steinmetzger
2017-12-07 23:48                   ` Wols Lists
2017-12-09 16:58                     ` J. Roeleveld
2017-12-09 18:28                       ` Wols Lists
2017-12-09 23:36                         ` Rich Freeman [this message]
2017-12-10  9:45                           ` Wols Lists
2017-12-10 15:07                             ` Rich Freeman
2017-12-10 21:00                               ` Wols Lists
2017-12-11  1:33                                 ` Rich Freeman
2017-12-11 23:20                 ` Frank Steinmetzger
2017-12-12 10:15                   ` Neil Bothwick
2017-12-12 12:18                     ` Wols Lists
2017-12-12 13:24                       ` Neil Bothwick
2017-12-07  7:54         ` Richard Bradfield
2017-12-07  9:28           ` Frank Steinmetzger
2017-12-07  9:52             ` Richard Bradfield
2017-12-07 14:53               ` Frank Steinmetzger
2017-12-07 15:26                 ` Rich Freeman
2017-12-07 16:04                   ` Frank Steinmetzger
2017-12-07 23:09                     ` Rich Freeman
2017-12-07 20:02                 ` Wols Lists
2017-12-07 18:35               ` Wols Lists
2017-12-07 20:17                 ` Richard Bradfield
2017-12-07 20:39                   ` Wols Lists

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='CAGfcS_nAaDVkT6v=_3cmhi_o90UFxF_YXg3O6GEDwLT-7QGozg@mail.gmail.com' \
    --to=rich0@gentoo.org \
    --cc=gentoo-user@lists.gentoo.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