Can't mount: open_ctree failed!

Can't mount: open_ctree failed!

[Florian Lindner]

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 

Re: Can't mount: open_ctree failed!

[Robert White]

On 11/02/2014 07:18 AM, Florian Lindner wrote:
> # btrfsck /dev/sdb1
> # btrfsck --init-extent-tree /dev/sdb1
> # btrfsck --init-csum-tree /dev/sdb1

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...

Re: Can't mount: open_ctree failed!

[Duncan]

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

> On 11/02/2014 07:18 AM, Florian Lindner wrote:
>> # btrfsck /dev/sdb1
>> # btrfsck --init-extent-tree /dev/sdb1
>> # btrfsck --init-csum-tree /dev/sdb1
> 
> 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...

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

Re: Can't mount: open_ctree failed!

[Florian Lindner]

Robert White wrote:

> On 11/02/2014 07:18 AM, Florian Lindner wrote:
>> # btrfsck /dev/sdb1
>> # btrfsck --init-extent-tree /dev/sdb1
>> # btrfsck --init-csum-tree /dev/sdb1
> 
> 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...

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

Florian

Re: Can't mount: open_ctree failed!

[Chris Murphy]

On Nov 2, 2014, at 8:18 AM, Florian Lindner <mailinglists@xgm.de> wrote:

> 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.

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.


> # 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)

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

Re: Can't mount: open_ctree failed!

[Florian Lindner]

Chris Murphy wrote:

> 
> On Nov 2, 2014, at 8:18 AM, Florian Lindner <mailinglists@xgm.de> wrote:
> 
>> 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.
> 
> 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.
> 
> 
>> # 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)
> 
> 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.

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
 

Re: Can't mount: open_ctree failed!

[Chris Murphy]

On Nov 3, 2014, at 12:48 PM, Florian Lindner <mailinglists@xgm.de> wrote:
> 
> 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.

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.

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

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