From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs check inconsistency with raid1, part 1
Date: Mon, 21 Dec 2015 10:23:31 +0800 [thread overview]
Message-ID: <567762A3.9060007@cn.fujitsu.com> (raw)
In-Reply-To: <CAJCQCtRyCxiAKDuyX-F_5Kmn8Xq+RruEo=H-S32FJPr_=b33TA@mail.gmail.com>
Chris Murphy wrote on 2015/12/20 19:12 -0700:
> On Sun, Dec 20, 2015 at 6:43 PM, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
>>
>>
>> Chris Murphy wrote on 2015/12/20 15:31 -0700:
>
>>> I think the cause is related to bus power with buggy USB 3 LPM
>>> firmware (these enclosures are cheap maybe $6). I've found some
>>> threads about this being a problem, but it's not expected to cause any
>>> corruptions. So, the fact Btrfs picks up one some problems might prove
>>> that (somewhat) incorrect.
>>
>>
>> Seems possible. Maybe some metadata just failed to reach disk.
>> BTW, did I asked for a btrfs-show-super output?
>
> Nope. I will attach to this email below for both devices.
>
>> If that's the case, superblock on device 2 maybe older than superblock on
>> device 1.
>
> Yes, looks iike devid 1 transid 4924, and devid 2 transid 4923. And
> it's devid 2 that had device reset and write errors when it vanished
> and reappeared as a different block device.
>
Now all the problem is explained.
You should be good to mount it rw, as RAID1 will handle all the problem.
Then you can either use scrub on dev2 to fix all the generation mismatch.
Although I prefer to wipe dev2 and mount dev1 as degraded, and replace
the missing dev2 with a good device/usb port.
Thanks,
Qu
next prev parent reply other threads:[~2015-12-21 2:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 4:16 btrfs check inconsistency with raid1, part 1 Chris Murphy
2015-12-14 5:48 ` Qu Wenruo
2015-12-14 7:24 ` Chris Murphy
2015-12-14 8:04 ` Qu Wenruo
2015-12-14 17:59 ` Chris Murphy
2015-12-20 22:32 ` Chris Murphy
[not found] ` <CAJCQCtSEx_wYPkfazik0bcpQwXxJCA=O5f0o6RbxON4jjB4q7A@mail.gmail.com>
[not found] ` <5677592F.5000202@cn.fujitsu.com>
2015-12-21 2:12 ` Chris Murphy
2015-12-21 2:23 ` Qu Wenruo [this message]
2015-12-21 2:46 ` Chris Murphy
2015-12-22 1:05 ` Kai Krakow
2015-12-22 1:22 ` Qu Wenruo
2015-12-22 1:48 ` Kai Krakow
2015-12-22 2:15 ` Qu Wenruo
2015-12-22 4:21 ` Chris Murphy
2015-12-22 10:23 ` Duncan
2015-12-22 15:44 ` Austin S. Hemmelgarn
2015-12-29 21:33 ` Chris Murphy
2015-12-14 11:51 ` 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=567762A3.9060007@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox