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 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.