public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: copies= option
Date: Sun, 4 May 2014 03:27:16 +0000 (UTC)	[thread overview]
Message-ID: <pan$9bead$d5bbe620$2c7141f7$fab07860@cox.net> (raw)
In-Reply-To: 201405041216.54348.russell@coker.com.au

Russell Coker posted on Sun, 04 May 2014 12:16:54 +1000 as excerpted:

> Are there any plans for a feature like the ZFS copies= option?
> 
> I'd like to be able to set copies= separately for data and metadata.  In
> most cases RAID-1 provides adequate data protection but I'd like to have
> RAID-1 and copies=2 for metadata so that if one disk dies and another
> has some bad sectors during recovery I'm unlikely to lose metadata.

Hugo's the guy with the better info on this one, but until he answers...

The zfs license issues mean it's not an option for me and I'm thus not 
familiar with its options in any detail, but if I understand the question 
correctly, yes.

And of course since btrfs treats data and metadata separately, it's 
extremely unlikely that any sort of copies= option wouldn't be separately 
configurable for each.

There was a discussion of a very nice multi-way-configuration schema that 
I deliberately stayed out of as both a bit above my head and far enough 
in the future that I didn't want to get my hopes up too high about it 
yet.  I already want N-way-mirroring so bad I can taste it, and this was 
that and way more... if/when it ever actually gets coded and committed to 
the mainline kernel btrfs.  As I said, Hugo should have more on it, as he 
was active in that discussion as it seemed to line up perfectly with his 
area of interest.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2014-05-04  3:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-04  2:16 copies= option Russell Coker
2014-05-04  3:27 ` Duncan [this message]
2014-05-04  7:27   ` Brendan Hide
     [not found]   ` <xjTK1n01B308YdQ01jTMAf>
2014-05-04 18:12     ` Duncan
2014-05-04 18:31       ` Hugo Mills
2014-05-05  2:59         ` Duncan
2014-05-06 20:13       ` Chris Murphy

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='pan$9bead$d5bbe620$2c7141f7$fab07860@cox.net' \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox