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
next prev parent 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