Can't mount: open_ctree failed!

Hello,

all after sudden I can't mount my btrfs home partition anymore. System is Arch with kernel 3.17.2, but I use snapper which does snapshopts regularly and I had 3.17.1 before, which afaik had some problems with snapshops.

Trying to mount without any options gives to the syslog:

Nov 02 16:04:16 horus kernel: BTRFS: mismatching generation and 
generation_v2 found in root item. This root was probably mounted with an 
older kernel. Resetting all new fields.
Nov 02 16:04:16 horus kernel: parent transid verify failed on 2121534193664 
wanted 1073784832 found 45541
Nov 02 16:04:16 horus kernel: parent transid verify failed on 2121534193664 
wanted 1073784832 found 45541
Nov 02 16:04:16 horus kernel: BTRFS: open_ctree failed

btrfsck quits after about half a minute with

# btrfsck /dev/sdb1
root item for root 3377, current bytenr 2122078191616, current gen 
8589934592, current level 64, new bytenr 2122078191616, new gen 49443, new 
level 1
root 3377 has a root item with a more recent gen (8589934592) compared to 
the found root node (49443)

I also tried -s 0 or -s 1 or -b options to btrfsck, as well as

# btrfsck --init-extent-tree /dev/sdb1
root 3377 has a root item with a more recent gen (8589934592) compared to 
the found root node (49443)

# btrfsck --init-csum-tree /dev/sdb1
Creating a new CRC tree
root 3377 has a root item with a more recent gen (8589934592) compared to 
the found root node (49443)

Mounting with -o recovery gives exact the same error. My usual mount options were defaults,compress=lzo,subvol=__current.

I also tried btrfs-zero-log but this does not change anything either.

Any ideas are deeply appreciated! Please help!

Florian

Notably missing from all these commands is "--repair"...

I don't know that's your problem for sure, but it's where I would start...

Robert White posted on Sun, 02 Nov 2014 14:31:36 -0800 as excerpted:

Well, btrfs check --repair has been actively discouraged for some time, unless (one or more of three):

1) You have a backup of the raw devices (which of course means you must have room for it).

2) Your next step would be to give up and do a mkfs, since in that case you're taking zero additional risk.

3) You have posted here with the logs, etc, and a btrfs dev has suggested using --repair as the problem indicated in the logs is known to be handled correctly by btrfs check --repair.

The problem is that while btrfs check getting better, certainly when the --repair option was first introduced and still to some extent, there's a non-zero risk that btrfs check won't recognize and fix the real problem, but instead will make the situation worse.

So STARTING with --repair has been actively discouraged.

That said, the --init-* options are pretty serious already, with their own risks, and indeed, in the general case (that is, where --init-* isn't known to be the correct fix based on the logs), I'd suggest trying --repair before trying them.

But do be careful about suggesting that people /start/ with --repair, because there have certainly been people who posted logs where some other fix was indicated, that ended up making things unrecoverable because --repair did the wrong thing for that error at that point in time, screwing things up such that even btrfs restore couldn't retrieve files. I think it has actually been awhile since the risk of --repair seriously damaging the filesystem instead of simply refusing to do anything if it didn't understand the problem was substantial, but it's still non-zero, and if people don't have backups and want anything off the filesystem, either getting full raw device backups first or doing the btrfs restore first to get what they can off the filesystem without chance of damaging it further, before trying anything that does have such a chance, even if it's remote, is a good idea.

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Sorry, forgot to mention it. Of course I tried all command with --repair.

Florian

It was with creating read-only snapshots. I forget if snapper's snapshots are ro. If they are then you need to use 3.17 btrfs-progs to fix it.

Did you use btrfs-image before using --repair?

Once you've done an init-extent-tree and it still won't mount, you're almost certainly in btrfs restore territory. Get the data out while you still can. And then you can check the recent patches from Josef for fsck that aren't yet in btrfs-progs 3.17. I'm not sure if they're in David's master branch, worth checking. There's a good chance it won't make things worse, might even fix the file system, but there's a fair chance it'll totally toast it. So definitely btrfs restore important stuff first.

Chris Murphy

Ok, problem is that I need to organise another hard disk for that. ;-)

I tried restore for a test run, it gave a lot of messages about wrong compression length. I found some discussion about that, but I don't know if its indicates an actual error or not? I did use compression on the drive.

Is there some guarantee that the data restore restores are correct or is it just a I try what I can do...

Thanks,
Florian

This is btrfs-progs 3.17? I know there were compression problems with kernel code but that was fixed in 3.16. I can't tell you why it happens on 3.17 or whether it's a bogus error.

No guarantee as far as I know, it's file scraping. There is a recent email from Duncan on this topic about two ways to do restore and he was doing both to make sure he got everything. I vaguely recall things like links aren't restored. Files themselves should be. There's a wiki entry on how to use restore that's worth looking at. In conjunction with btrfs-debug-tree -R you should be able to find a state where you can restore important files.

Chris Murphy