From: Gregory L Shomo <greg@techsquare.com>
To: linux-btrfs@vger.kernel.org
Subject: parent transid troubles
Date: Tue, 19 Apr 2011 15:08:13 -0400 [thread overview]
Message-ID: <sa2hb9u9i02.fsf@techsquare.com> (raw)
Hello list-
Under heavy load (i/o), one of our fileservers lost two drives
in a raid6 configuration. After the drives were synchronized,
we can no longer mount the multiple-device btrfs filesystem
due to (at least) parent transid verification.
btrfsck built from git commit 1b444cd2e6ab8dcafdd47dbaeaae369dd1517c17
runs for a while and then aborts on 'failed to find block number'.
Sample output includes :
parent transid verify failed on 22569952096256 wanted 176066 found
176064
parent transid verify failed on 22569952096256 wanted 176066 found
176064
parent transid verify failed on 20403515183104 wanted 176066 found
174710
parent transid verify failed on 20403515183104 wanted 176066 found
174710
parent transid verify failed on 1265784008704 wanted 176066 found
175341
!-- snip
bad block 1099696562176
leaf parent key incorrect 1117248647168
!-- snip
Extent back ref already exists for 1130294538240 parent 0 root 2
Extent back ref already exists for 1130295001088 parent 0 root 2
!-- snip
fs uuid d8464857-db87-412e-9d57-ece6c2054f40
chunk uuid 52a652a3-650d-4dd7-aaa2-6f096a714bbf
item 0 key (20407857930240 EXTENT_ITEM 4096) itemoff 3944
itemsize 51
extent refs 1 gen 165193 flags 2
tree block key (257306671 1 0) level 0
tree block backref root 5
item 1 key (20407857934336 EXTENT_ITEM 4096) itemoff 3893
itemsize 51
extent refs 1 gen 165308 flags 2
tree block key (257585950 1 0) level 0
tree block backref root 5
!-- snip
failed to find block number 20407858008064
Aborted
Output is exactly the same when run against both devices, even
when using 'btrfsck -s1'.
Should we light a candle and say 'goodbye' to the data or is
there some hope that btrfsck will be able to help us mount the
filesystem ?
Is there any additional information that is useful to the developers ?
The system is based on fedora-14, btrfs-progs-0.19-12.fc14.x86_64,
and the arcmsr module (built from the 1.20.0X.15-100729 sources).
- greg
next reply other threads:[~2011-04-19 19:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 19:08 Gregory L Shomo [this message]
2011-04-19 19:34 ` parent transid troubles Chris Mason
2011-04-20 12:56 ` Gregory L Shomo
2011-04-20 13:06 ` Chris Mason
2011-04-20 13:20 ` Gregory L Shomo
2011-04-20 14:04 ` Chris Mason
2011-04-20 20:53 ` Gregory L Shomo
2011-04-20 20:54 ` Chris Mason
2011-05-04 18:04 ` Gregory L Shomo
2011-05-25 18:03 ` Gregory L Shomo
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=sa2hb9u9i02.fsf@techsquare.com \
--to=greg@techsquare.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).