BTRFS corrupted by combination of mistreatment of hiberantion and accidental power loss.

I have two independent Linux installations my notebook, both sharing the same btrfs partition as root file system, but installed on different subvolumes.

I hibernated one Linux (Mint 15 64 bit). Hibernation data is stored on the swap file, which is used exclusively by this system.

Then 2 events happened.

1) I accidentally ran the other system, which wasn't hibernated - Ubuntu 12.10. Realizing the problem, I waited until the system booted up, and then shutdowned it.

Then I opened the hibernated Mint 15. Restoration went successful, and I never thought I am in trouble.

2) Immediately after that, by coincidence, the battery fell down, brutally powering down the computer.

After that, I am unable to repair/mount the root btrfs partition, however I try (I built the current btrfs-tools from git). Dmesg displays only one error entry: btrfs: open_ctree failed.

I know, that if one those two events happened separately, there would be no problem. The problem arose only when those two events happened simultaneously.

So I guess I am experiencing one of the corner cases.

What are my prospects to restoring my data? I have several subvolumes on the hard drive, some of them were not touched by the accident at all.

Adam Ryczkowski

!!!

!!!!!

You were already screwed at this point. The following power-down is irrelevant, and this is not a BTRFS-specific issue either.

What you did was kind of like plugging a HDD into one computer, then at the same time plugging it into another one (let's imagine this would be possible) then "waiting until the system booted up" at the second one, shutting it down, then expecting the 1st computer doesn't notice a thing. But then again from your initial post I wonder will you realize why such imagined scenario would cause any problem.

With respect,
Roman

You'd have been better off to just throw away the hiberated image:
mounting the filesystem would look like any other recovery from a crash, and would have replayed the log and committed a new transaction, in addition to whatever other disk writes happened due to boot logs and so forth.

In this case, I suspect you'd have been perfectly fine.

When resuming the hibernated image at that point however, the kernel will have its own ideas about the state on disk (i.e., whatever state it had in memory), partially undoing a subset of the changes from the previous boot and generally making a mess of things.

That said, have you tried mounting with -o recovery yet? I wouldn't be surprised if btrfs-restore was also able to retrieve most of everything. Either way, I'd be suspicious of the filesystem, and would look to restore from backup to a fresh fs.

cwillu posted on Wed, 29 Jan 2014 09:13:44 -0600 as excerpted:

What he said, plus try mounting with the nospace_cache option. I've had crashes kill that tree... only, and sometimes... If that works, try clear_spacecache (not sure on the _s and I'm headed for work so look that bit up).

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