Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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.

There is only a use case for this tools: when you have BTRFS: failed to read log tree 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 explain 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
If this works, your should be able to boot your Linux.
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.
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.
                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.
– Special Sauce
                Sep 3, 2022 at 9:38
logs were full with parent transid verify failed on 109973766144 wanted 1823 found 1821
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
NAS with 3 nfs shares
BTRFS file system
Rockstor Operating System
RAID 10 setup
additional information
the btrfs mount became read only
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 
                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?!
– Tones29
                Mar 27, 2019 at 17:16
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
                If you restored data to another disk, how do you make the old drive (here: /dev/sda4) usable again? Formatting?
– Christian
                Nov 27, 2020 at 13:49
                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.
– Fusca Software
                Dec 15, 2020 at 1:14
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.