From: Oliver Mangold <o.mangold@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: coredump in btrfsck
Date: Wed, 01 Jan 2014 22:27:43 +0100 [thread overview]
Message-ID: <52C4884F.6040000@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2850 bytes --]
I fear, I broke my FS by running btrfsck. I tried 'btrfsck --repair' and
it fixed several problems but finally crashed with some debug message
from 'extent-tree.c', so I also tried 'btrfsck --repair
--init-extent-tree'. Since then I can't mount the FS anymore:
> mount -t btrfs /dev/mapper/primary-home /home
produces log messages:
Jan 01 21:45:09 home kernel: btrfs: device fsid
31a5d433-4f7b-49cc-9bc0-9422471f5194 devid 1 transid 4793
/dev/mapper/primary-home
Jan 01 21:45:09 home kernel: btrfs: disk space caching is enabled
Jan 01 21:45:09 home kernel: parent transid verify failed on 2176851968
wanted 4792 found 4793
Jan 01 21:45:09 home kernel: parent transid verify failed on 2176851968
wanted 4792 found 4793
Jan 01 21:45:09 home kernel: btrfs: open_ctree failed
The FS operates in RAID1-mode over 2 block devices
/dev/mapper/primary-home and /dev/mapper/secondary-home. Trying to rerun
'btrfsck --repair' or 'btrfsck --repair --init-extent-tree' (for both
devices) still exits with a debug assertion:
> btrfsck --repair /dev/mapper/primary-home
parent transid verify failed on 2176851968 wanted 4792 found 4793
Ignoring transid failure
checking extents
bad block 2783195136
ref mismatch on [1103101952 4096] extent item 0, found 1
incorrect offsets 3200 4794
btrfsck: extent-tree.c:2717: alloc_reserved_tree_block: Assertion
`!(ret)' failed.
enabling repair mode
Checking filesystem on /dev/mapper/primary-home
UUID: 31a5d433-4f7b-49cc-9bc0-9422471f5194
> btrfsck --repair /dev/mapper/secondary-home
parent transid verify failed on 2176851968 wanted 4792 found 4793
Ignoring transid failure
checking extents
bad block 2783195136
ref mismatch on [1103101952 4096] extent item 0, found 1
incorrect offsets 3200 4794
btrfsck: extent-tree.c:2717: alloc_reserved_tree_block: Assertion
`!(ret)' failed.
enabling repair mode
Checking filesystem on /dev/mapper/secondary-home
UUID: 31a5d433-4f7b-49cc-9bc0-9422471f5194
> btrfsck --repair --init-extent-tree /dev/mapper/primary-home
parent transid verify failed on 2176851968 wanted 4792 found 4793
Ignoring transid failure
btrfsck: root-tree.c:80: btrfs_update_root: Assertion `!(ret != 0)' failed.
enabling repair mode
Checking filesystem on /dev/mapper/primary-home
UUID: 31a5d433-4f7b-49cc-9bc0-9422471f5194
Creating a new extent tree
> btrfsck --repair --init-extent-tree /dev/mapper/secondary-home
parent transid verify failed on 2176851968 wanted 4792 found 4793
Ignoring transid failure
btrfsck: root-tree.c:80: btrfs_update_root: Assertion `!(ret != 0)' failed.
enabling repair mode
Checking filesystem on /dev/sda1
UUID: 31a5d433-4f7b-49cc-9bc0-9422471f5194
Creating a new extent tree
Can the FS be repaired or at least the data be recovered? Apparently I
found a bug in btrfsck which needs fixing. If it helps, I attached the
output of 'btrfs-debug-tree -e'.
[-- Attachment #2: debug-tree.log.gz --]
[-- Type: application/gzip, Size: 27584 bytes --]
next reply other threads:[~2014-01-01 21:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-01 21:27 Oliver Mangold [this message]
2014-01-01 21:58 ` coredump in btrfsck Chris Murphy
2014-01-01 22:35 ` Oliver Mangold
2014-01-02 17:37 ` Chris Murphy
2014-01-03 12:33 ` Marc MERLIN
2014-01-04 0:14 ` Chris Murphy
2014-01-05 6:13 ` Marc MERLIN
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=52C4884F.6040000@gmail.com \
--to=o.mangold@gmail.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