All of lore.kernel.org
 help / color / mirror / Atom feed
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/


  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.