fix btrfs "btrfs parent transid verify failed on ..."

Question

btrfs fi show displays all btrfs file system but also a lot of errors like:

parent transid verify failed on 109973766144 wanted 1823 found 1821

The filesystem can still be unmounted and remounted.

Ba

Answer 1

Surfing the web I found a lot of answers recommending to clear btrfs' internal log by using btrfs-zero-log. I thought btrfsck could help but eventually I discovered the official recommendation which is to first just start a btrfs scrub before taking other actions!

So just run btrfs scrub /path/to/mountpoint if you too can still mount your filesystem. And maybe it works like in my case.

Ba

Answer 2

Beware of btrfs-zero-log

btrfs-zero-log documentation states clearly that it's not a generic tool to use:

btrfs-zero-log is not a general fix-everything tool, despite what many people believe and state around the internet. You generally don't need to use it.

So there is only single use case for this tools: when you see the BTRFS: failed to read log tree message in your logs.

Fixing parent transid verify failed errors with usebackuproot

The 3.2 Linux kernel introduced in January 2012 the recovery option. Then, in May 2016 with the 4.6 version, it was superseded by usebackuproot. You can also see the commit if you're interested.

The documentation explains clearly what it does:

usebackuproot
nousebackuproot

    (since: 4.6, default: off)

    Enable autorecovery attempts if a bad tree root is found at mount time.
    Currently this scans a backup list of several previous tree roots and
    tries to use the first readable. This can be used with read-only mounts as well.

    Note: This option has replaced recovery.

A note in the official FAQ section states that this is the right way to fix this "parent transid" error:

How do I recover from a "parent transid verify failed" error?

For example:

parent transid verify failed on 29360128 wanted 1486656 found 1486662

If the second two numbers (wanted 1486656 and found 1486662) are close together (within about 20 of each other), then mounting with

-o ro,usebackuproot

may help. If it's successful with a read-only mount, then try again without the ro option, for a read-write mount.

If the usebackuproot doesn't work, then the FS is basically unrecoverable in its current state with current tools. You should use btrfs restore to refresh your backups, and then restore from them.

Commands to use

These commands are just example of a failed btrfs disk on a Fedora installation. Replace /dev/sda2 with your device and /sysroot with your mount point

First try in read only mode:

mount -t btrfs -o ro,usebackuproot /dev/sda2 /sysroot

If that works, try again without the readonly command:

mount -t btrfs -o usebackuproot /dev/sda2 /sysroot

Now, if that command have worked without errors, your should be able to boot your Linux.

Algarroba

Mounting it will not make it to pass btrfsck – Caisson

My sincere gratitude to you. After many hours of troubleshooting various approaches to this issue (unable to mount a raw btrfs image), your suggestion of using the usebackuproot option resolved the problem. I can also confirm that- in my case- the parent transid verify check was only off by one. – Fled

Answer 3

First run this command:

sudo btrfs rescue super-recover -v /dev/sda2

If it tells you “All supers are valid, no need to recover”, you need to run the following command to clear the filesystem log tree:

sudo btrfs rescue zero-log /dev/sda2

Now you should be able to mount your Btrfs file system.

Receiver

This command worked for me even though the other commands above did not. This command found two good supers and one bad super. After I confirmed the filesystem was indeed BTRFS, it went ahead and recovered the 1 bad super. After that, I was able to boot successfully. – Citrus

Answer 4

I faced a similar situation:

1. logs were full with parent transid verify failed on 109973766144 wanted 1823 found 1821
2. dmesg was full with BTRFS info (device sda): no csum found for inode 16485445 start 73728 and BTRFS warning (device sda): csum failed ino 16485465 off 36864 csum 2268363541 expected csum 0

configuration of my system

3. NAS with 3 nfs shares
4. BTRFS file system

5. Rockstor Operating System

6. RAID 10 setup

additional information

7. the btrfs mount became read only

8. btrfs-scrub failed with ERROR: scrubbing /dev/md124p2 failed for device id 1: ret=-1, errno=5

I solved it by deleting the nfs export ie. from /etc/export/ and then remounting the volumes and voila everything became ok

UPDATE 29 Jan 2018: after working for a few days it went back exactly to the same state

Nudism

I experienced a very similar issue: 4HDDs in RAID 10 with madm, BTRFS file system (ubuntu 18.04, kernel 4.18), access over samba. dmesg reported a lot of errors similar to your error, a quarter of all files could not be opened (I/O error), btrfs scrub failed with the same error code. Disabling the samba service and remounting the file system cured all problems like a charm. I will now setup a new NAS configuration with ext4 instead of btrfs as I do not trust this file system any more. Seems like there is a bug when interacting with nfs/samba in such configurations?! – Motif

Answer 5

Similar/Same problem here:

parent transid verify failed on 29605888 wanted 50 found 46

---

For me the btrfs is not mountable anymore so btrfs scrub is no option. Also my /etc/exports are empty.

I tried btrfsck --init-extent-tree /dev/sda4 but I still get errors.

    ...
    btrfs check(main+0x82)[0x411ba2]
    /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f8210fab555]
    btrfs check[0x411ca8]
    Aborted
    #

Link to Screenshot (Updload wasn't possible): Screenshot

It seems the only solution is to restore the data to another disk by

btrfs restore /dev/sda4 /mnt/anotherdisk/folder

.

Lineman

If you restored data to another disk, how do you make the old drive (here: /dev/sda4) usable again? Formatting? – Herniotomy

It was a virtual machine with virtual disks, so I created a new virtual disk. the restore also did not recover all mysql files well so the system was crashed forever. – Lineman