Problems with transid in btrfs (linux 3.13)

[George Shuklin]

Hello.

We've got issues with volume mount on 3.13.0-43-generic with btrfs after crash due to OOM. I filed bug to bugzilla on kernel.org and they replied that bug has been fixed in newer version and it should be backported to 3.13.

Bugzilla's original bugreport: https://bugzilla.kernel.org/show_bug.cgi?id=96251

Trace in the kernel:

parent transid verify failed on 471304036352 wanted 407770 found 407769
parent transid verify failed on 471304036352 wanted 407770 found 407769
btrfs: failed to read log tree
btrfs: open_ctree failed

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1441150

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[George Shuklin (george-shuklin)]

This bug happened on server which already rebooted (PXE boot), so apport is useless.

[Colin Ian King (colin-king)]

George, I downloaded http://c2154.eu01.webzillafiles.com/btrfs/btrfs_image.xz and uncompressed it, but can't figure out how you mounted it - it just appears as raw data and I can't determine where the btrfs file system is on that image. Any clues?

[George Shuklin (george-shuklin)]

It is not a filesystem (em... original filesystem was 2Tb in size), it's a result of btrfs-image command. I used it according to https://btrfs.wiki.kernel.org/index.php/Btrfs-zero-log: "Please Email the btrfs list, explain the problem, and offer your filesystem image to a developer. "

I think there should be some way to recreate a filesystem from this meta without actual data (inside files). But I'm not the kernel or filesystem developer to play with this.

[Colin Ian King (colin-king)]

That makes sense, I couldn't find any superblock IDs on the data using 'grep "_BHRfS_M" test'

[Colin Ian King (colin-king)]

I've restored that data and tries to mount it with today's latest 4.0-rc7 kernel and I still hit the transid verify failed errors, so I can't get the image mounted even with the latest kernel.

I think it is a little disingenuous for the bug to be marked as "won't fix" on the bugzilla because of the older 3.13 kernel when we hit the same issues with the the upstream kernel.

[Colin Ian King (colin-king)]

I've restored the data and all kernels from Ubuntu-3.13.0-91.138 through to the latest upstream v4.7-rc6 can attempt to mount the restored data without oopsing the kernel. However, the data I have is definitely broken and cannot be mounted, even btrfs-image -r on the image reports a transid failure that is not fixable:

$ btrfs-image -r btrfs_image btrfs_image_restored
parent transid verify failed on 471304036352 wanted 407771 found 407769
parent transid verify failed on 471304036352 wanted 407771 found 407769
Ignoring transid failure

So, since the kernel is not oopsing now, I think this a fix released for 3.13