All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin <m_btrfs@ml1.co.uk>
To: linux-btrfs@vger.kernel.org
Subject: btrfsck --repair --init-extent-tree: segfault error 4
Date: Mon, 07 Oct 2013 15:56:44 +0100	[thread overview]
Message-ID: <l2ui33$vjd$1@ger.gmane.org> (raw)
In-Reply-To: <l2p3ja$v8r$1@ger.gmane.org>

Any clues or educated comment please?

Can the corrupt directory tree safely be ignored and left in place? Or
might that cause everything to fall over in a big heap as soon as I try
to write data again?


Could these other tricks work-around or fix the corrupt tree:

Run a scrub?

Make a snapshot and work from the snapshot?

Or try "mount -o recovery,noatime" again?


Or is it dead?

(The 1.5TB of backup data is replicated elsewhere but it would be good
to rescue this version rather than completely redo from scratch.
Especially so for the sake of just a few MBytes of one corrupt directory
tree.)

Thanks,
Martin



On 05/10/13 14:18, Martin wrote:
> So...
> 
> The hint there is "btrfsck: extent-tree.c:2736", so trying:
> 
> btrfsck --repair --init-extent-tree /dev/sdc
> 
> That ran for a while until:
> 
> kernel: btrfsck[16610]: segfault at cc ip 000000000041d2a7 sp
> 00007fffd2c2d710 error 4 in btrfsck[400000+4d000]
> 
> There's no other messages in the syslog.
> 
> The output attached.
> 
> 
> What next?
> 
> 
> Thanks,
> Martin
> 
> 
> 
> On 05/10/13 12:32, Martin wrote:
>> 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




  reply	other threads:[~2013-10-07 14:56 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
2013-10-05 13:18                 ` Martin
2013-10-07 14:56                   ` Martin [this message]
2013-10-07 19:03                     ` btrfsck --repair --init-extent-tree: segfault error 4 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='l2ui33$vjd$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 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.