All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin <m_btrfs@ml1.co.uk>
To: linux-btrfs@vger.kernel.org
Subject: Re: Corrupt btrfs filesystem recovery... What best instructions?
Date: Fri, 04 Oct 2013 16:43:20 +0100	[thread overview]
Message-ID: <l2mnmf$us$1@ger.gmane.org> (raw)
In-Reply-To: <l2k7kd$1dh$1@ger.gmane.org>

What best to try next?

mount "-o recovery,noatime"

btrfsck:
    --repair                    try to repair the filesystem
    --init-csum-tree            create a new CRC tree
    --init-extent-tree          create a new extent tree

or is a "scrub" worthwhile?


The fail and switch to read-only occured whilst trying to delete a known
bad directory tree. No worries for losing the data in that.

But how best to clean up the filesystem errors?


Thanks,
Martin




On 03/10/13 17:56, Martin wrote:
> On 03/10/13 01:49, Martin wrote:
> 
>> Summary:
>>
>> Mounting "-o recovery,noatime" worked well and allowed a diff check to
>> complete for all but one directory tree. So very nearly all the data is
>> fine.
>>
>> Deleting the failed directory tree caused a call stack dump and eventually:
>>
>> kernel: parent transid verify failed on 915444822016 wanted 16974 found
>> 13021
>> kernel: BTRFS info (device sdc): failed to delete reference to
>> eggdrop-1.6.19.ebuild, inode 2096893 parent 5881667
>> kernel: BTRFS error (device sdc) in __btrfs_unlink_inode:3662: errno=-5
>> IO failure
>> kernel: BTRFS info (device sdc): forced readonly
>>
>>
>> Greater detail listed below.
>>
>> What next best to try?
>>
>> Safer to try again but this time with with "no_space_cache,no_inode_cache"?
>>
>> Thanks,
>> Martin
> 
> 
>> Next best step to try?
>>
>> Remount "-o recovery,noatime" again?
> 
> 
> 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-04 15:43 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 [this message]
2013-10-05 11:32               ` Martin
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='l2mnmf$us$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.