From: Russell Coker <russell@coker.com.au>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: staggered stripes
Date: Fri, 16 May 2014 00:38:04 +1000 [thread overview]
Message-ID: <4172915.as80o3hoBa@xev> (raw)
In-Reply-To: <pan$a10c6$96b782de$86a74a2f$b7f37af@cox.net>
On Thu, 15 May 2014 09:31:42 Duncan wrote:
> > Does the BTRFS RAID functionality do such staggered stripes? If not
> > could it be added?
>
> AFAIK nothing like that yet, but it's reasonably likely to be implemented
> later. N-way-mirroring is roadmapped for next up after raid56
> completion, however.
It's RAID-5/6 when we really need such staggering. It's a reasonably common
configuration choice to use two different brands of disk for a RAID-1 array.
As the correlation between parts of the disks with errors only applied to
disks of the same make and model (and this is expected due to
firmware/manufacturing issues) the people who care about such things on RAID-1
have probably already dealt with the issue.
> You do mention the partition alternative, but not as I'd do it for such a
> case. Instead of doing a different sized buffer partition (or using the
> mkfs.btrfs option to start at some offset into the device) on each
> device, I'd simply do multiple partitions and reorder them on each
> device.
If there are multiple partitions on a device then that will probably make
performance suck. Also does BTRFS even allow special treatment of them or
will it put two copies from a RAID-10 on the same disk?
> Tho N-way-mirroring would sure help here too, since if a given
> area around the same address is assumed to be weak on each device, I'd
> sure like greater than the current 2-way-mirroring, even if if I had a
> different filesystem/partition at that spot on each one, since with only
> two-way-mirroring if one copy is assumed to be weak, guess what, you're
> down to only one reasonably reliable copy now, and that's not a good spot
> to be in if that one copy happens to be hit by a cosmic ray or otherwise
> fail checksum, without another reliable copy to fix it since that other
> copy is in the weak area already.
>
> Another alternative would be using something like mdraid's raid10 "far"
> layout, with btrfs on top of that...
In the "copies= option" thread Brendan Hide stated that this sort of thing is
planned.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
next prev parent reply other threads:[~2014-05-15 14:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 9:00 staggered stripes Russell Coker
2014-05-15 9:31 ` Duncan
2014-05-15 14:38 ` Russell Coker [this message]
2014-05-15 16:15 ` Brendan Hide
2014-05-15 16:18 ` Hugo Mills
[not found] ` <2Ee51o00g0uXw0U01Ee7j5>
2014-05-16 4:17 ` Duncan
2014-05-15 9:34 ` Hugo Mills
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=4172915.as80o3hoBa@xev \
--to=russell@coker.com.au \
--cc=1i5t5.duncan@cox.net \
--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.