All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <koen@dominion.thruhere.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)
Date: Fri, 9 Jun 2017 22:10:40 +0200	[thread overview]
Message-ID: <ohevbq$r7e$1@blaine.gmane.org> (raw)
In-Reply-To: <20170609195718.GC30723@carfax.org.uk>

Op 09-06-17 om 21:57 schreef Hugo Mills:
> On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote:
>> Hi,
>>
>> Today the kernel got wedged during shutdown (4.11.x tends to do that, haven't
>> debugged) and I pressed the reset button. The next boot btrfs won't mount:
>>
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): failed to read block groups: -5
>> [Fri Jun  9 20:46:08 2017] BTRFS error (device md0): open_ctree failed
> 
>    With a transid failure on mount, about the only thing that's likely
> to work is mounting with -o usebackuproot. If that doesn't work, then
> a rebuild of the FS is almost certainly needed.

Hrm, that is also a no-go:

# mount /dev/md0 /media/data/  -o usebackuproot

[  740.294141] BTRFS info (device md0): trying to use backup root at mount time
[  740.294145] BTRFS info (device md0): using free space tree
[  740.294146] BTRFS info (device md0): has skinny extents
[  754.248228] BTRFS error (device md0): parent transid verify failed on 5840011722752 wanted 170755 found 170832
[  754.449435] BTRFS error (device md0): parent transid verify failed on 5840011722752 wanted 170755 found 170832
[  754.449527] BTRFS error (device md0): failed to read block groups: -5
[  754.609960] BTRFS error (device md0): open_ctree failed

So, any more suggestions of things to try?

regards,

Koen

> 
>    Hugo.
> 
>> I tried repair, but that didn't work either:
>>
>> # btrfsck --repair /dev/md0
>> enabling repair mode
>> couldn't open RDWR because of unsupported option features (3).
>> ERROR: cannot open file system
>> enabling repair mode
>>
>> Googling around it was suggested clearing the v2 space cache:
>>
>> # btrfsck --mode=lowmem --clear-space-cache v2 /dev/md0
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> parent transid verify failed on 5840011722752 wanted 170755 found 170832
>> Ignoring transid failure
>> leaf parent key incorrect 5840011722752
>> parent transid verify failed on 5367057465344 wanted 170755 found 170828
>> parent transid verify failed on 5367057465344 wanted 170755 found 170828
>> parent transid verify failed on 5367057465344 wanted 170755 found 170828
>> parent transid verify failed on 5367057465344 wanted 170755 found 170828
>> Ignoring transid failure
>> leaf parent key incorrect 72105984
>> btrfs unable to find ref byte nr 4628577484800 parent 0 root 10  owner 0 offset 1
>> parent transid verify failed on 5366993256448 wanted 170755 found 170827
>> parent transid verify failed on 5366993256448 wanted 170755 found 170827
>> parent transid verify failed on 5366993256448 wanted 170755 found 170827
>> parent transid verify failed on 5366993256448 wanted 170755 found 170827
>> Ignoring transid failure
>> leaf parent key incorrect 41287680
>> ERROR: failed to clear free space cache v2: -1
>> transaction.h:41: btrfs_start_transaction: BUG_ON `root->commit_root` triggered, value 22938400
>> btrfs check[0x411674]
>> btrfs check(close_ctree_fs_info+0x125)[0x41368c]
>> btrfs check(cmd_check+0x36d8)[0x45e8e8]
>> btrfs check(main+0x15d)[0x40ac5c]
>> /lib/libc.so.6(__libc_start_main+0xf0)[0x7f9b4cb060d0]
>> btrfs check[0x40a729]
>> Clear free space cache v2
>>
>> The underlying md0 (raid6) doesn't report any errors, trying different kernels makes no difference, 4.10.17, 4.11.4 and 4.12.0-rc4 all give the same errors. Everything above was
>> done with btrfs-progs 4.11.
>>
>> Any hints on how I can fix the errors in the filesystem? I don't mind loosing todays changes, but I would like to keep all the older data :)
>>
>> regards,
>>
>> Koen
>>
> 



  reply	other threads:[~2017-06-09 20:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-09 19:12 Filesystem won't mount (open_ctree failed) or repair (BUG_ON) Koen Kooi
2017-06-09 19:57 ` Hugo Mills
2017-06-09 20:10   ` Koen Kooi [this message]
2017-06-11  4:20   ` Chris Murphy
2017-06-11 10:05     ` Koen Kooi
2017-06-11 10:13       ` Koen Kooi
2017-06-11 23:00         ` Chris Murphy
2017-06-12  6:35           ` Koen Kooi
2017-06-11 22:58       ` Chris Murphy
2017-06-12  5:18         ` Koen Kooi
2017-06-12  6:12         ` Koen Kooi

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='ohevbq$r7e$1@blaine.gmane.org' \
    --to=koen@dominion.thruhere.net \
    --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.