Re: Lost /home subvolume after btrfs crash

[Martin Wilck <mwilck@arcor.de>]

On 04/24/2014 05:15 AM, Chris Murphy wrote:

>>> Current stable is 3.14.1, I suggest giving 3.13 or 3.14 a shot at this with -o ro,recovery as a first step and see if it at least mounts.
>>
>> I will. Note that with 12.3, which was the most recent media I had at
>> hand at the time, the FS was actually mountable at first (-o
>> ro,recovery). But there was no /home and later attempts to actually
>> access data in other subvolumes failed with the messages in my debug
>> material.
> 
> I'd skip 3.13 and go straight to 3.14.1 or 3.15rc2, and use mount option -o ro,recovery straight away and see if you can extract all of /home.

I tried mount -o ro,recovery with 3.14.1 (3.14.1-vanilla from OpenSUSE
tumbleweed), but results weren't better than before. The kernel choked
on the FS. The attempt to mount the broken FS with -o ro,recovery ended
with a kernel Oops:

BTRFS error (device dm-18): unable to find ref byte nr 980791296 parent
0 root 2  owner 0 offset 0
BUG: unable to handle kernel paging request at ff000000
IP: [<c0324cab>] page_address+0xb/0xd0
[<f926deef>] btrfs_del_items+0xdf/0x390
[<f9275636>] __btrfs_free_extent+0x796/0xb30
[<f927a81c>] __btrfs_run_delayed_refs+0x8dc/0x10e0
[<f9276c21>] ? btrfs_delayed_refs_qgroup_accounting+0xa1/0xe0
[<f927ec96>] btrfs_run_delayed_refs.part.56+0x56/0x1f0
[<f92a963f>] ? btrfs_run_ordered_operations+0x19f/0x220
[<f927ee3f>] btrfs_run_delayed_refs+0xf/0x20
[<f928e0cc>] btrfs_commit_transaction+0x3c/0xbf0
...

After that, the system was basically dead, all IO would be blocked by
some deadlock in btrfs.

Full kernel log again under
https://www.dropbox.com/sh/utv8b3qd0do6a04/zTwGQCrN9x.

> You could then try btrfs-progs v3.14's btrfs restore to extract
> /home. 

btrfs restore from btrfs-progs 3.14.1 definitely looked more promising
than the version I tried previously. However, /home is still empty.

> If that doesn't work then I'd give up on this instance of the
> file system as it sounds damaged by something possibly even the
> btrfsck --repair.

I made the block-level copy before trying any write operation (IOW,
before copying, I tried only btrfs-restore and mount -ro,recovery).
So it should be a 1:1 copy of the broken FS.

I can't easily give up this data,

> I wouldn't use --repair until a dev recommends it (even with btrfs-progs v3.14 let alone the I'm guessing v0.19 or v0.20 you were using); or once all other reasonable options are exhausted.

Well it seems as if all "reasonable" options are indeed exhausted :-(
Still looking for ideas to recover the contents of /home.

Would it make sens to try to check out previous generations of the root
tree with btrfs recover?

Regards
Martin

> 
> 
> Chris Murphy