linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Seeger <p0h0i0l0i0p@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Crash during mount -o degraded, kernel BUG at fs/btrfs/extent_io.c:2044
Date: Sun, 1 Nov 2015 00:36:42 +0100	[thread overview]
Message-ID: <5635508A.4080401@googlemail.com> (raw)
In-Reply-To: <5635140F.7040206@googlemail.com>

On 10/31/2015 08:18 PM, Philip Seeger wrote:
> On 10/23/2015 01:13 AM, Erik Berg wrote:
>> So I intentionally broke this small raid6 fs on a VM to learn recovery
>> strategies for another much bigger raid6 I have running (which also
>> suffered a drive failure).
>>
>> Basically I zeroed out one of the drives (vdd) from under the running
>> vm. Then ran an md5sum on a file on the fs to trigger some detection of
>> data inconsistency. I ran a scrub, which completed "ok". Then rebooted.
>>
>> Now trying to mount the filesystem in degraded mode leads to a kernel
>> crash.
>
> I've tried this on a system running kernel 4.2.5 and got slightly
> different results.

And I've now tried it with kernel 4.3-rc7 and got similar results.

> Created a raid6 array with 4 drives and put some stuff on it. Zeroed out
> the second drive (sdc) and checked the md5 sums of said stuff (all OK,
> good) which caused errors to be logged (dmesg) complaining about
> checksum errors on the 4th drive (sde):
> BTRFS warning (device sde): csum failed ino 259 off 1071054848 csum
> 2566472073 expected csum 3870060223

Same issue, this time sdd. The error message appears to chose a random 
device.

> This error mentions a file which is still correct:

Same issue.

> However, the scrub found uncorrectable errors, which shouldn't happen in
> a raid6 array with only 1 bad drive:

This did not happen, the scrub fixed errors and found no uncorrectable 
errors.

> But it looks like there are still some "invisible" errors on this (now
> empty) filesystem; after rebooting and mounting it, this one error is
> logged:
> BTRFS: bdev /dev/sdc errs: wr 0, rd 0, flush 0, corrupt 199313, gen 0

However, this "invisible" error shows up even with this kernel version.

So I'm still wondering why this error is happening even after a 
successful scrub.



Philip

  reply	other threads:[~2015-10-31 23:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-22 23:13 Crash during mount -o degraded, kernel BUG at fs/btrfs/extent_io.c:2044 Erik Berg
2015-10-31 19:18 ` Philip Seeger
2015-10-31 23:36   ` Philip Seeger [this message]
2015-11-01  3:22     ` Duncan
2015-11-01 13:58       ` Philip Seeger
2015-11-01 13:44   ` Anand Jain

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=5635508A.4080401@googlemail.com \
    --to=p0h0i0l0i0p@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).