From: Andreas Reis <andreas.reis@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Bug: "corrupt leaf. slot offset bad": root subvolume unmountable, "btrfs check" crashes
Date: Mon, 21 Apr 2014 18:16:41 +0200 [thread overview]
Message-ID: <53554469.5070503@gmail.com> (raw)
Kernel 3.15.0-rc2, btrfs-progs 3.14.1
While doing some minor package updates my btrfs root partition [*]
decided to corrupt itself. There was no system crash, although I had
plenty of these (due to an USB-related regression) in recent weeks that
resulted in no trouble.
First only one of a package's folders was corrupted, any access to files
within (incl. attempts to delete) printed
btrfs: corrupt leaf, slot offset bad: block=842924032,root=1, slot=88
to dmesg (I'm actually not sure about the numbers, but that was indeed
the error message). After moving the folder out of the way the partition
continued to appear working as normal, one reboot also worked fine.
Now I can't boot at all (beyond loading the kernel image located on
another partition), neither with 3,15-rc2 nor 3.14.1. Attempting to
mount the __current/ROOT subvolume on ArchLinux's current Live-CD
(kernel 3.13.7) prints
btrfs: device label Linux devid 1 transid 55586 /dev/sdc5
btrfs: use ssd allocation scheme
btrfs: disk space caching is enabled
btrfs: checking UUID tree
btrfs: corrupt leaf, slot offset bad: block=842924032,root=1, slot=88
btrfs: corrupt leaf, slot offset bad: block=842924032,root=1, slot=88
BTRFS error (device sdc5): Error removing orphan entry, stopping orphan
cleanup
BTRFS critical (device sdc5): could not do orphan cleanup -22
Doing "btrfs check /dev/sdc5" merely first prints ten
free space inode generation (0) did not match free space cache
generation ([different transids between 40010 and 55578])
to then abort with
checking fs roots
btrfs: cmds-check.c:1151: procecss_file_extent: Assertion `!(rec->ino !=
key->objectid || rec->refs > 1)' failed.
I'm reluctant to try any of "btrfs check" options (or mount with -o
recovery) since the last three times I did this (with other partitions)
it resulted in the partition becoming entirely trashed, while before at
least "btrfs restore" still managed to extract some data each time.
The affected folder was one within /usr/include/qt4 (which I then moved
to /usr/BROKEN, to successfully reinstall the package), ie. on the
__current/ROOT subvolume.
Which seems the only subvolume affected (yet). Mounting & accessing the
other three (__current/{var,home,opt}) still works.
[*] Organised following
http://blog.fabio.mancinelli.me/2012/12/28/Arch_Linux_on_BTRFS.html
(Also posted on https://bugzilla.kernel.org/show_bug.cgi?id=74611 )
next reply other threads:[~2014-04-21 16:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-21 16:16 Andreas Reis [this message]
2014-04-21 19:13 ` Bug: "corrupt leaf. slot offset bad": root subvolume unmountable, "btrfs check" crashes Andreas Reis
2014-04-21 23:44 ` Duncan
2014-04-22 18:16 ` Andreas Reis
2014-04-23 2:55 ` Duncan
2014-04-25 2:04 ` Bug: Andreas Reis
2014-04-25 2:43 ` Bug: Partition borked Andreas Reis
2014-04-25 3:03 ` Chris Murphy
2014-04-23 15:02 ` Bug: "corrupt leaf. slot offset bad": root subvolume unmountable, "btrfs check" crashes Andreas Reis
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=53554469.5070503@gmail.com \
--to=andreas.reis@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;
as well as URLs for NNTP newsgroup(s).