From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Scrubbing with BTRFS Raid 5
Date: Wed, 22 Jan 2014 15:39:27 +0000 (UTC) [thread overview]
Message-ID: <pan$90f3c$88756f33$d6abe04$395cafd4@cox.net> (raw)
In-Reply-To: DC8CDADE-5C7A-4DA3-8081-EB631136621B@gmail.com
Graham Fleming posted on Tue, 21 Jan 2014 10:03:26 -0800 as excerpted:
> I want to keep playing around with BTRFSS RAID 5 and testing with it...
> assuming I have a drive with bad blocks, or let's say some inconsistent
> parity am I right in assuming that a) a btrfs scrub operation will not
> fix the stripes with bad parity
What I know is that it is said btrfs scrub doesn't work with btrfs raid5/6
yet. I don't know how it actually fails (tho I'd hope it simply returns
an error to the effect that it doesn't work with raid5/6 yet) as I've not
actually tried that mode, here.
> and b) a balance operation will not be
> successful? Or would a balance operation work to re-write parity?
Balance actually rewrites everything (well, everything matching its
filters if a filtered balance is used, everything, if not), so it should
rewrite parity correctly.
AFAIK, all the writing works and routine read works. It's the error
recovery that's still only partially implemented. Since reading just
reads data, not parity unless there's a dropped device or the like to
recover from, as long as all devices are active and there's a good copy
of the data (based on btrfs checksumming) to read, the rebalance should
just use and rewrite that, ignoring the bad parity.
--
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-01-22 15:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 18:03 Scrubbing with BTRFS Raid 5 Graham Fleming
2014-01-22 15:39 ` Duncan [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-01-21 9:06 Graham Fleming
2014-01-21 17:08 ` Duncan
2014-01-21 17:18 ` Jim Salter
2014-01-21 17:38 ` Chris Murphy
2014-01-21 18:25 ` Jim Salter
2014-01-22 16:02 ` Duncan
2014-01-22 20:45 ` Chris Mason
2014-01-22 21:06 ` ronnie sahlberg
2014-01-22 21:16 ` Chris Mason
2014-01-22 22:36 ` ronnie sahlberg
2014-01-20 0:53 Graham Fleming
2014-01-20 13:21 ` Duncan
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$90f3c$88756f33$d6abe04$395cafd4@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