From: Waxhead <waxhead@online.no>
To: Chris Murphy <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs scrub failure for raid 6 kernel 4.3
Date: Wed, 30 Dec 2015 19:31:59 +0100 [thread overview]
Message-ID: <5684231F.7040700@online.no> (raw)
In-Reply-To: <CAJCQCtSZHpdLhkbSMfJi0RmV9Sa1_h4ea8yJzJMc3CxoLGhK+A@mail.gmail.com>
Chris Murphy wrote:
> Well all the generations on all devices are now the same, and so are
> the chunk trees. I haven't looked at them in detail to see if there
> are any discrepancies among them.
>
> If you don't care much for this file system, then you could try btrfs
> check --repair, using btrfs-progs 4.3.1 or integration branch. I have
> no idea where btrfsck repair is at with raid56.
>
> On the one hand, corruption should be fixed by scrub. But scrub fails
> with a kernel trace. Maybe btrfs check --repair can fix the tree block
> corruption since scrub can't, and then if that corruption is fixed,
> possibly scrub will work.
>
I could not care less about this particular filesystem as I wrote in the
original post. It's just for having some fun with btrfs. What I find
troublesome is that corrupting one (or even two) drives in a Raid6
config fails. Granted the filesystem "works" e.g. I can mount it and
access files, but I get a input/output error on a file on this
filesystem and btrfs only shows warning (not errors) on device sdg1
where the csum failed.
A raid6 setup should work fine even if two missing disks (or in this
case chunks of data) is missing and even if I don't care about this
filesystem I care about btrfs getting stable ;) so if I can help I'll
keep this filesystem around for a little longer!
next prev parent reply other threads:[~2015-12-30 18:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-27 13:59 Btrfs scrub failure for raid 6 kernel 4.3 Waxhead
2015-12-27 18:29 ` Chris Murphy
2015-12-27 23:06 ` Waxhead
2015-12-28 1:48 ` Duncan
2015-12-28 2:04 ` Waxhead
2015-12-28 2:18 ` Chris Murphy
2015-12-28 21:08 ` Waxhead
2015-12-28 21:23 ` Chris Murphy
[not found] ` <5681BDD0.1060407@online.no>
2015-12-29 0:29 ` Chris Murphy
2015-12-29 20:19 ` Waxhead
2015-12-30 4:22 ` Chris Murphy
2015-12-30 18:31 ` Waxhead [this message]
2015-12-30 19:08 ` Waxhead
2015-12-28 4:02 ` Duncan
2015-12-28 21:17 ` Waxhead
2015-12-28 21:50 ` Chris Murphy
2015-12-28 0:39 ` Christoph Anton Mitterer
2015-12-28 0:58 ` Chris Murphy
2015-12-28 1:09 ` Christoph Anton Mitterer
2015-12-28 1:23 ` Chris Murphy
2015-12-28 1:31 ` Christoph Anton Mitterer
2015-12-28 2:16 ` Duncan
2015-12-28 1: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=5684231F.7040700@online.no \
--to=waxhead@online.no \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/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.