All of lore.kernel.org
 help / color / mirror / Atom feed
* corruption.  notreelog has no effect? anything else to try?
@ 2011-07-15 20:51 mck
  2011-07-15 22:19 ` Fajar A. Nugraha
  0 siblings, 1 reply; 4+ messages in thread
From: mck @ 2011-07-15 20:51 UTC (permalink / raw)
  To: linux-btrfs

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: corruption. notreelog has no effect? anything else to try?
  2011-07-15 20:51 corruption. notreelog has no effect? anything else to try? mck
@ 2011-07-15 22:19 ` Fajar A. Nugraha
  2011-07-17  0:28   ` Mck
  0 siblings, 1 reply; 4+ messages in thread
From: Fajar A. Nugraha @ 2011-07-15 22:19 UTC (permalink / raw)
  To: linux-btrfs

On Sat, Jul 16, 2011 at 3:51 AM, mck <mick@wever.org> wrote:
> My laptop btrfs partition has become corrupt after a power+battery
> outage.
>
> # btrfs-show
> Label: none =A0uuid: e7b37e5d-c704-4ca8-ae7e-f22dd063e165
> =A0 =A0 =A0 =A0Total devices 1 FS bytes used 116.33GB
> =A0 =A0 =A0 =A0devid =A0 =A01 size 226.66GB used 226.66GB path /dev/s=
da4
>
> I typically mount w/
> =A0 =A0 =A0 =A0-o subvol=3Dxyz,compress,noatime,nodiratime
> =A0and take snapshots of (some) subvolumes at every boot.
> =A0(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/
> =A0 =A0found 124906840074 bytes used err is 1
> =A0 =A0total csum bytes: 117696892
> =A0 =A0total tree bytes: 4385128448
> =A0 =A0total fs tree bytes: 3926626304
> =A0 =A0btree space waste bytes: 1078295916
> =A0 =A0file data blocks allocated: 3619739602944
> =A0 =A0 referenced 162976624640
> =A0 =A0Btrfs Btrfs v0.19
>

does btrfsck -s1 complete without error? If yes, you can try btrfs-sele=
ct-super.

>
> mounting always results in the crash
>
> [ 6977.513528] Call Trace:
> [ 6977.513542] =A0[<ffffffffa057ac18>] replay_one_dir_item+0x88/0xb0 =
[btrfs]
> [ 6977.513557] =A0[<ffffffffa057d5b3>] replay_one_buffer+0x223/0x330 =
[btrfs]
> [ 6977.513573] =A0[<ffffffffa056a8ba>] ? alloc_extent_buffer+0x7a/0x4=
20 [btrfs]
> [ 6977.513584] =A0[<ffffffffa057c139>] walk_down_log_tree+0x339/0x480=
 [btrfs]
> [ 6977.513595] =A0[<ffffffffa057c375>] walk_log_tree+0xf5/0x230 [btrf=
s]
> [ 6977.513606] =A0[<ffffffffa057f1c1>] btrfs_recover_log_trees+0x221/=
0x310 [btrfs]

if there's something mentioning "log", I'd try btrfs-zero-log first.
It's not built by default, so you should run "make btrfs-zero-log" on
btrfs-tools source directory.

--=20
=46ajar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: corruption. notreelog has no effect? anything else to try?
  2011-07-17  0:28   ` Mck
@ 2011-07-17  0:26     ` Fajar A. Nugraha
  0 siblings, 0 replies; 4+ messages in thread
From: Fajar A. Nugraha @ 2011-07-17  0:26 UTC (permalink / raw)
  To: linux-btrfs

On Sun, Jul 17, 2011 at 7:28 AM, Mck <mick@wever.org> wrote:
> Knowing very little about zero-log and select-super should i continue
> using my laptop like normal now?
> Or is this filesystem still considered corrupt and i should backup and
> format it all from scratch?

This is my guess:
- since you clear the log, there might be corruption on files that you
worked on when the crash occured.
- since btrfs uses cow, snapshots created (and not being accessed)
before the crash should be fine
- check syslog for weird logs

If no new error log comes up, and the files you're working on before
are intact, I'd just keep on using it.

-- 
Fajar

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: corruption. notreelog has no effect? anything else to try?
  2011-07-15 22:19 ` Fajar A. Nugraha
@ 2011-07-17  0:28   ` Mck
  2011-07-17  0:26     ` Fajar A. Nugraha
  0 siblings, 1 reply; 4+ messages in thread
From: Mck @ 2011-07-17  0:28 UTC (permalink / raw)
  To: linux-btrfs

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

> does btrfsck -s1 complete without error? 
> If yes, you can try btrfs-select-super.
> [snip]
> if there's something mentioning "log", I'd try btrfs-zero-log first.

`btrfsck -s1 /dev/sda4` gave errors too. 
So i skipped to running btrfs-zero-log. It ran without errors.
But running btrfsck again still gave the same errors.

So i went back and tried btrfs-select-super...

# ./btrfs-select-super -s1 /dev/sda4
using SB copy 1, bytenr 67108864

After this i tried mounting and it worked for all subvolumes!
I am ever so grateful for your help Fajar.
 
Unfortunately I didn't try mounting after the btrfs-zero-log so i don't
know if it or btrfs-select-super was actually the cure.

Knowing very little about zero-log and select-super should i continue
using my laptop like normal now?
Or is this filesystem still considered corrupt and i should backup and
format it all from scratch?


~mck


-- 
“Don’t worry about people stealing your ideas. If your ideas are any
good, you’ll have to ram them down people’s throats.” - Howard Aiken 
| http://semb.wever.org | http://sesat.no
| http://tech.finn.no       | Java XSS Filter

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-07-17  0:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-15 20:51 corruption. notreelog has no effect? anything else to try? mck
2011-07-15 22:19 ` Fajar A. Nugraha
2011-07-17  0:28   ` Mck
2011-07-17  0:26     ` Fajar A. Nugraha

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.