From: Roman Mamedov <rm@romanrm.net>
To: Malte Westerhoff <MWesterhoff@visageimaging.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs partition fails to mount after power outage
Date: Tue, 23 Aug 2016 21:06:15 +0500 [thread overview]
Message-ID: <20160823210615.06e30854@natsu> (raw)
In-Reply-To: <FBA93BA3BE574649A3C97265F3CE0D54013A625685@ber-vi4.ad.vi>
[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]
On Tue, 23 Aug 2016 12:30:35 +0000
Malte Westerhoff <MWesterhoff@visageimaging.com> wrote:
> parent transid verify failed on 7375567323136 wanted 52059 found 52045
> parent transid verify failed on 7375567323136 wanted 52059 found 52045
> Error: could not find btree root extent for root 12974
>
> This is kernel 4.1.27 and btrfs-progs 4.1.2. We also tried the btrfs check --repair with btrfs-progs 4.7 with the same result.
>
> The partition with the problem is /dev/mapper/VGBIGRAID6-DATA1
> (The partition is an LVM logical volume that is on top of an md raid6.)
>
> Anything else that we can try in order to recover the volume?
In my experience the last resort solution to this is to simply kill the
problematic block with the "btrfs-corrupt-block" tool (compile from
btrfs-progs source), then run "btrfs check --repair" again, and this time it
should quite trivially set things right. See my success story about that:
http://www.spinics.net/lists/linux-btrfs/msg53061.html
and especially note the part about making COW snapshots of the entire block
device (should be easier since you already run LVM), which will allow you to
experiment while having an ability to undo.
Some files will be lost or corrupted (likely only an extremely tiny portion,
but not knowing which -- sucks), so ideally you should always have means to
verify the integrity of user data on any FS. At least for those which change
infrequently, e.g. media file libraries, always keep '*.sfv' files produced by
the 'cfv' tool beside everything. Also something along the lines of
cd /mnt/mydata && find > /somewhereelse/mydata-`date -Iseconds`.lst
in crontab.
Before starting you can also try checking what kind of data the problematic
block contains, IIRC it would be (but not guaranteed to be helpful):
btrfs-debug-tree -b 7375567323136 /dev/mapper/VGBIGRAID6-DATA1
--
With respect,
Roman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
prev parent reply other threads:[~2016-08-23 16:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-23 12:30 btrfs partition fails to mount after power outage Malte Westerhoff
2016-08-23 14:52 ` Chris Murphy
2016-08-23 15:19 ` Malte Westerhoff
2016-08-23 15:45 ` Chris Murphy
2016-08-23 15:51 ` Malte Westerhoff
2016-08-23 16:05 ` Chris Murphy
2016-08-23 16:07 ` Chris Murphy
2016-08-23 16:29 ` Malte Westerhoff
2016-08-23 16:06 ` Roman Mamedov [this message]
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=20160823210615.06e30854@natsu \
--to=rm@romanrm.net \
--cc=MWesterhoff@visageimaging.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).