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


  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.