From: mck <mick@wever.org>
To: linux-btrfs@vger.kernel.org
Subject: corruption. notreelog has no effect? anything else to try?
Date: Fri, 15 Jul 2011 20:51:41 +0000 [thread overview]
Message-ID: <1310763102.3972.31.camel@ubuntu> (raw)
My laptop btrfs partition has become corrupt after a power+battery
outage.
# btrfs-show
Label: none uuid: e7b37e5d-c704-4ca8-ae7e-f22dd063e165
Total devices 1 FS bytes used 116.33GB
devid 1 size 226.66GB used 226.66GB path /dev/sda4
I typically mount w/
-o subvol=xyz,compress,noatime,nodiratime
and take snapshots of (some) subvolumes at every boot.
(not that these snapshots seem to be of much use now).
Now:
btrfsck gives loads of "root x inode y errors 400" and finishes w/
found 124906840074 bytes used err is 1
total csum bytes: 117696892
total tree bytes: 4385128448
total fs tree bytes: 3926626304
btree space waste bytes: 1078295916
file data blocks allocated: 3619739602944
referenced 162976624640
Btrfs Btrfs v0.19
mounting always results in the crash
[ 6977.513528] Call Trace:
[ 6977.513542] [<ffffffffa057ac18>] replay_one_dir_item+0x88/0xb0 [btrfs]
[ 6977.513557] [<ffffffffa057d5b3>] replay_one_buffer+0x223/0x330 [btrfs]
[ 6977.513573] [<ffffffffa056a8ba>] ? alloc_extent_buffer+0x7a/0x420 [btrfs]
[ 6977.513584] [<ffffffffa057c139>] walk_down_log_tree+0x339/0x480 [btrfs]
[ 6977.513595] [<ffffffffa057c375>] walk_log_tree+0xf5/0x230 [btrfs]
[ 6977.513606] [<ffffffffa057f1c1>] btrfs_recover_log_trees+0x221/0x310 [btrfs]
[ 6977.513618] [<ffffffffa057d390>] ? replay_one_buffer+0x0/0x330 [btrfs]
[ 6977.513629] [<ffffffffa0541353>] ? btree_read_extent_buffer_pages.clone.63+0x73/0xb0 [btrfs]
[ 6977.513642] [<ffffffffa0544f8e>] open_ctree+0x125e/0x15c0 [btrfs]
[ 6977.513651] [<ffffffff812e5404>] ? snprintf+0x34/0x40
[ 6977.513659] [<ffffffffa0523e18>] btrfs_fill_super.clone.9+0x78/0x130 [btrfs]
[ 6977.513666] [<ffffffff811cc2f4>] ? disk_name+0x64/0xc0
[ 6977.514286] [<ffffffff812e1fe7>] ? strlcpy+0x47/0x60
[ 6977.514880] [<ffffffffa0524223>] btrfs_mount+0x353/0x400 [btrfs]
[ 6977.515479] [<ffffffff81149f45>] ? alloc_pages_current+0xa5/0x110
[ 6977.516077] [<ffffffff8116745d>] vfs_kern_mount+0x8d/0x280
[ 6977.516684] [<ffffffff811676c4>] do_kern_mount+0x54/0x110
[ 6977.517281] [<ffffffff81184c8a>] do_mount+0x1ea/0x230
[ 6977.517885] [<ffffffff811850b0>] sys_mount+0x90/0xe0
[ 6977.518489] [<ffffffff8100c002>] system_call_fastpath+0x16/0x1b
[ 6977.519090] Code: ff ff 48 8b 0b 4d 89 f8 48 8b bd 78 ff ff ff 4c 89 ea 4c 89 e6 c7 04 24 01 00 00 00 e8 2a 2e fc ff 49 89 c6 e9 a1 fe ff ff 0f 0b <0f> 0b 0f 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41
[ 6977.519767] RIP [<ffffffffa057a8e0>] replay_one_name+0x2a0/0x2b0 [btrfs]
Looking at the dump i'd thought/hoped that either "-o ro" or "-o
notreelog" might get me around the problem, but no. Neither does it
matter which subvolume i try to mount. If this is a tree log problem is
there any other way of getting around this?
At this point i've pretty much given up and am ready to restore from
backups. But thought i should take the time to report the situation...
and it there's any extra advice/recipes to savage data on offer i'm keen
to try.
I do have a btrfs-image i can upload if it's of any help...
~mck
next reply other threads:[~2011-07-15 20:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-15 20:51 mck [this message]
2011-07-15 22:19 ` corruption. notreelog has no effect? anything else to try? Fajar A. Nugraha
2011-07-17 0:28 ` Mck
2011-07-17 0:26 ` Fajar A. Nugraha
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=1310763102.3972.31.camel@ubuntu \
--to=mick@wever.org \
--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.