From: Tim Walberg <twalberg@comcast.net>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Tim Walberg <twalberg@comcast.net>, linux-btrfs@vger.kernel.org
Subject: Re: recovering from "parent transid verify failed"
Date: Thu, 15 Aug 2019 08:52:51 -0500 [thread overview]
Message-ID: <20190815135251.GC2731@comcast.net> (raw)
In-Reply-To: <4be5086f-61e7-a108-8036-da7d7a5d5c11@gmx.com>
Had to wait for 'btrfs recover' to finish before I proceed farther.
Kernel is 4.19.45, tools are 4.19.1
File system is a 3-disk RAID10 with WD3003FZEX (WD Black 3TB)
Output from attempting to mount:
# mount -o ro,usebackuproot /dev/sdc1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
Kernel messages from the mount attempt:
[Thu Aug 15 08:47:42 2019] BTRFS info (device sdc1): trying to use backup root at mount time
[Thu Aug 15 08:47:42 2019] BTRFS info (device sdc1): disk space caching is enabled
[Thu Aug 15 08:47:42 2019] BTRFS info (device sdc1): has skinny extents
[Thu Aug 15 08:47:42 2019] BTRFS error (device sdc1): parent transid verify failed on 229846466560 wanted 49749 found 49750
[Thu Aug 15 08:47:42 2019] BTRFS error (device sdc1): parent transid verify failed on 229846466560 wanted 49749 found 49750
[Thu Aug 15 08:47:42 2019] BTRFS error (device sdc1): failed to read block groups: -5
[Thu Aug 15 08:47:42 2019] BTRFS error (device sdc1): open_ctree failed
Output from 'btrfs check -p /dev/sdc1':
# btrfs check -p /dev/sdc1
Opening filesystem to check...
parent transid verify failed on 229846466560 wanted 49749 found 49750
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=229845336064 item=0 parent level=1 child level=2
ERROR: cannot open file system
On 08/15/2019 10:35 +0800, Qu Wenruo wrote:
>>
>>
>> On 2019/8/15 ??????2:32, Tim Walberg wrote:
>> > Most of the recommendations I've found online deal with when "wanted" is
>> > greater than "found", which, if I understand correctly means that one or
>> > more transactions were interrupted/lost before fully committed.
>>
>> No matter what the case is, a proper transaction shouldn't have any tree
>> block overwritten.
>>
>> That means, either the FLUSH/FUA of the hardware/lower block layer is
>> screwed up, or the COW of tree block is already screwed up.
>>
>> >
>> > Are the recommendations for recovery the same if the system is reporting a
>> > "wanted" that is less than "found"?
>> >
>> The salvage is no difference than any transid mismatch, no matter if
>> it's larger or smaller.
>>
>> It depends on the tree block.
>>
>> Please provide full dmesg output and btrfs check for further advice.
>>
>> Thanks,
>> Qu
>>
--
+----------------------+
| Tim Walberg |
| 830 Carriage Dr. |
| Algonquin, IL 60102 |
| twalberg@comcast.net |
+----------------------+
next prev parent reply other threads:[~2019-08-15 13:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 18:32 recovering from "parent transid verify failed" Tim Walberg
2019-08-15 2:35 ` Qu Wenruo
2019-08-15 13:52 ` Tim Walberg [this message]
2019-08-15 14:07 ` Qu Wenruo
2019-08-15 14:21 ` Tim Walberg
2019-08-15 14:45 ` Qu Wenruo
2019-08-15 15:01 ` Tim Walberg
2019-08-15 13:55 ` Tim Walberg
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=20190815135251.GC2731@comcast.net \
--to=twalberg@comcast.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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.