From: Martin <m_btrfs@ml1.co.uk>
To: linux-btrfs@vger.kernel.org
Subject: Re: Corrupt btrfs filesystem recovery... What best instructions?
Date: Sat, 05 Oct 2013 12:32:41 +0100 [thread overview]
Message-ID: <l2otcg$mh$1@ger.gmane.org> (raw)
In-Reply-To: <l2mnmf$us$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
No comment so blindly trying:
btrfsck --repair /dev/sdc
gave the following abort:
btrfsck: extent-tree.c:2736: alloc_reserved_tree_block: Assertion
`!(ret)' failed.
Full output attached.
All on:
3.11.2-gentoo
Btrfs v0.20-rc1-358-g194aa4a
For a 2TB single HDD formatted with defaults.
What next?
Thanks,
Martin
>> In the meantime, trying:
>>
>> btrfsck /dev/sdc
>>
>> gave the following output + abort:
>>
>> parent transid verify failed on 915444523008 wanted 16974 found 13021
>> Ignoring transid failure
>> btrfsck: cmds-check.c:1066: process_file_extent: Assertion `!(rec->ino
>> != key->objectid || rec->refs > 1)' failed.
>> id not match free space cache generation (1625)
>> free space inode generation (0) did not match free space cache
>> generation (1607)
>> free space inode generation (0) did not match free space cache
>> generation (1604)
>> free space inode generation (0) did not match free space cache
>> generation (1606)
>> free space inode generation (0) did not match free space cache
>> generation (1620)
>> free space inode generation (0) did not match free space cache
>> generation (1626)
>> free space inode generation (0) did not match free space cache
>> generation (1609)
>> free space inode generation (0) did not match free space cache
>> generation (1653)
>> free space inode generation (0) did not match free space cache
>> generation (1628)
>> free space inode generation (0) did not match free space cache
>> generation (1628)
>> free space inode generation (0) did not match free space cache
>> generation (1649)
>>
>>
>> (There was no syslog output.)
>>
>> Full btrfsck listing attached.
>>
>>
>> Suggestions please?
>>
>> Thanks,
>> Martin
[-- Attachment #2: btrfsck_repair_sdc.log --]
[-- Type: text/x-log, Size: 3965 bytes --]
checking extents
leaf parent key incorrect 907183771648
bad block 907183771648
leaf parent key incorrect 907183779840
bad block 907183779840
leaf parent key incorrect 907183882240
bad block 907183882240
leaf parent key incorrect 907185160192
bad block 907185160192
leaf parent key incorrect 907185201152
bad block 907185201152
leaf parent key incorrect 915432497152
bad block 915432497152
leaf parent key incorrect 915432509440
bad block 915432509440
leaf parent key incorrect 915432513536
bad block 915432513536
leaf parent key incorrect 915432529920
bad block 915432529920
leaf parent key incorrect 915432701952
bad block 915432701952
leaf parent key incorrect 915433058304
bad block 915433058304
leaf parent key incorrect 915437543424
bad block 915437543424
leaf parent key incorrect 915437563904
bad block 915437563904
leaf parent key incorrect 915444469760
bad block 915444469760
leaf parent key incorrect 915444473856
bad block 915444473856
leaf parent key incorrect 915444506624
bad block 915444506624
leaf parent key incorrect 915444518912
bad block 915444518912
leaf parent key incorrect 915444523008
bad block 915444523008
leaf parent key incorrect 915444527104
bad block 915444527104
leaf parent key incorrect 915444539392
bad block 915444539392
leaf parent key incorrect 915444543488
bad block 915444543488
leaf parent key incorrect 915444547584
bad block 915444547584
leaf parent key incorrect 915444551680
bad block 915444551680
leaf parent key incorrect 915444555776
bad block 915444555776
leaf parent key incorrect 915444559872
bad block 915444559872
leaf parent key incorrect 915444563968
bad block 915444563968
leaf parent key incorrect 915444572160
bad block 915444572160
leaf parent key incorrect 915444576256
bad block 915444576256
leaf parent key incorrect 915444580352
bad block 915444580352
leaf parent key incorrect 915444584448
bad block 915444584448
leaf parent key incorrect 915444588544
bad block 915444588544
leaf parent key incorrect 915444678656
bad block 915444678656
leaf parent key incorrect 915444682752
bad block 915444682752
leaf parent key incorrect 915444793344
bad block 915444793344
leaf parent key incorrect 915444797440
bad block 915444797440
leaf parent key incorrect 915444813824
bad block 915444813824
leaf parent key incorrect 915444817920
bad block 915444817920
leaf parent key incorrect 915444822016
bad block 915444822016
leaf parent key incorrect 915444826112
bad block 915444826112
leaf parent key incorrect 915444830208
bad block 915444830208
leaf parent key incorrect 915444834304
bad block 915444834304
leaf parent key incorrect 915444924416
bad block 915444924416
leaf parent key incorrect 915444973568
bad block 915444973568
leaf parent key incorrect 915444977664
bad block 915444977664
leaf parent key incorrect 915444981760
bad block 915444981760
parent transid verify failed on 915444973568 wanted 16974 found 13021
parent transid verify failed on 915444973568 wanted 16974 found 13021
parent transid verify failed on 915444977664 wanted 16974 found 13021
parent transid verify failed on 915444977664 wanted 16974 found 13021
parent transid verify failed on 915444981760 wanted 16974 found 13021
parent transid verify failed on 915444981760 wanted 16974 found 13021
parent transid verify failed on 915432701952 wanted 16974 found 16972
parent transid verify failed on 915432701952 wanted 16974 found 16972
parent transid verify failed on 915444678656 wanted 16974 found 13021
parent transid verify failed on 915444678656 wanted 16974 found 13021
parent transid verify failed on 915444682752 wanted 16974 found 13021
parent transid verify failed on 915444682752 wanted 16974 found 13021
deleting pointer to block 915432701952
owner ref check failed [907183771648 4096]
repair deleting extent record: key 907183771648 168 4096
btrfsck: extent-tree.c:2736: alloc_reserved_tree_block: Assertion `!(ret)' failed.
enabling repair mode
Checking filesystem on /dev/sdc
UUID: 38a60270-f9c6-4ed4-8421-4bf1253ae0b3
next prev parent reply other threads:[~2013-10-05 11:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-28 19:26 Corrupt btrfs filesystem recovery... (Due to *sata* errors) Martin
2013-09-28 20:51 ` Chris Murphy
2013-09-28 22:51 ` Martin
2013-09-29 2:06 ` Chris Murphy
2013-09-29 2:31 ` Martin
2013-09-28 22:54 ` Martin
2013-09-29 2:10 ` Corrupt btrfs filesystem recovery... What best instructions? Martin
2013-09-29 5:11 ` Duncan
2013-09-29 21:29 ` Martin
2013-09-29 21:55 ` Martin
2013-09-30 7:51 ` Duncan
2013-10-03 0:49 ` Martin
2013-10-03 1:31 ` Chris Murphy
2013-10-03 16:56 ` Martin
2013-10-04 15:43 ` Martin
2013-10-05 11:32 ` Martin [this message]
2013-10-05 13:18 ` Martin
2013-10-07 14:56 ` btrfsck --repair --init-extent-tree: segfault error 4 Martin
2013-10-07 19:03 ` Chris Murphy
2013-10-09 16:03 ` Martin
2013-10-05 12:05 ` ASM1083 rev01 PCIe to PCI Bridge chip (Was: Corrupt btrfs filesystem recovery... (Due to *sata* errors)) Martin
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='l2otcg$mh$1@ger.gmane.org' \
--to=m_btrfs@ml1.co.uk \
--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).