From: Robert White <rwhite@pobox.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: mkfs.btrfs limits "odd" [and maybe a "failed" phantom device?]
Date: Fri, 12 Dec 2014 03:16:03 -0800 [thread overview]
Message-ID: <548ACE73.3000000@pobox.com> (raw)
In-Reply-To: <20141212090647.GA5574@yadt.co.uk>
On 12/12/2014 01:06 AM, David Taylor wrote:
> The above quote is discussing two device RAID5, you are discussing
> three device RAID5.
Heresy! (yes, some humor is required here.)
There is no such thing as a "two device RAID5". That's what RAID1 is for.
Saying "The above quote is discussing a two device RAID5" is exactly
like saying "The above quote is discussing a two wheeled tricycle".
You might as well be talking about three-octet IP addresses. That is you
could make a network address out of three octets, but it wouldn't' be an
IP address. It would be something else with the wrong name attached.
I challenge you... nay I _defy_ you... to find a single authority on
disk storage anywhere on this planet (except, apparently, this list and
its directly attached people and materials) that discusses, describes,
or acknowledges the existence of a "two device RAID5" while not
discussing a system with an arity of 3 degraded by the absence of one media.
All these words have standardized definitions.
[That's not hyperbole. I searched for several hours and could not find
_any_ reference anywhere to construction of a RAID5 array using only two
devices that did not involve airity-3 and a dummy/missing/failed psudo
target. So if you can find any reference to doing this _anywhere_
outside of BTRFS I'd like to see it. Genuinely.]
THAT SAID...
I really can find no reason the math wouldn't work using only two
drives. It would be a terrific waste of CPU cycles and storage space to
construct the stripe buffers and do the XORs instead of just copying the
data, but the math would work.
So, um, "well I'll be damned".
Perhaps is just a tautological belief that someone here didn't buy into.
Like how people keep partitioning drives into little slices for things
because thats the preserved wisdom from early eighties.
I think constructing a non-degraded-mode two device thing and calling it
RAID5 will surprise virtually _everyone_ on the planet.
In every other system. And I do mean _every_ other system, if I had two
media and I put them under RAID-5 I'd be required to specify the third
drive as some sort failed device (the block device equivalent of
/dev/null but that returns error results for all operations instead of
successes.) See the reserved keyword "missing" in the mdadm
documentation etc.
That is, If I put two 1TiB disks into a RAID-5 I'd expect to get a 2TiB
array with no actual redundancy. As in
mdadm --create md0 --level=r5 --raid-devices=3 /dev/sda missing /dev/sdc
the resulting array would be the same effective size as a stripe of the
two drives, but when the third was added later it would just slot in as
a replacement for the missing device and the airity-3 thing would
"reestablish" it's redundancy. (this is actually what mdadm does
internally with a normal build, it blesses the first N-1 drives into an
array with a missing member, and adds the Nth drive as a "spare" and
then the spare is immediately adopted as a replacement for the "missing"
drive.)
The parity computation on a single value is just nutty waste of time
though. "Backing it out" when the array is degraded is double-nuts.
Maybe everybody just decided it was too crazy to consider for the CPU
time penalty...?
So yea, semantics... apparently...
next prev parent reply other threads:[~2014-12-12 11:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 22:18 mkfs.btrfs limits "odd" [and maybe a "failed" phantom device?] Robert White
2014-12-11 7:33 ` Duncan
2014-12-12 3:56 ` Zygo Blaxell
2014-12-12 6:01 ` Robert White
2014-12-12 9:06 ` David Taylor
2014-12-12 11:16 ` Robert White [this message]
2014-12-12 13:29 ` Hugo Mills
2014-12-13 3:01 ` Duncan
2014-12-12 16:45 ` Zygo Blaxell
2014-12-12 22:28 ` Robert White
2014-12-13 4:28 ` Zygo Blaxell
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=548ACE73.3000000@pobox.com \
--to=rwhite@pobox.com \
--cc=linux-btrfs@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.