I have an unmountable, unfixable Btrfs filesystem after a power failure during write.

It’s a backup itself, so nothing critical, but I am not comfortable using Btrfs, if a single power failure can completely trash a filesystem beyond repair. I though CoW is rugged exactly against that…

Whatever I try - I get the same output:

# btrfs check --repair --init-extent-tree /dev/sdc
enabling repair mode
Opening filesystem to check...
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: cannot open file system

I’ve tried everything so far, except for btrfs-zero-log, but I don’t have that tool!

I have btrfs-progs 4.20 installed, and no btrfs-zero-log to be found.
Where did it go? Where can I get it?
I’ve tried installing btrfs-progs-git from AUR, but it failed:

==> ERROR: One or more files did not pass the validity check!
==> ERROR: Makepkg was unable to build btrfs-progs-git.

For the sake of completness:

# mount /dev/sdc backup
mount: /mnt/backup: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error.
# btrfs restore -xmSvi /dev/sdc .
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
Could not open root, trying backup super
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
Could not open root, trying backup super
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
Could not open root, trying backup super
# btrfs check --repair /dev/sdc
enabling repair mode
Opening filesystem to check...
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: cannot open file system
# btrfs check --repair --init-csum-tree /dev/sdc
enabling repair mode
Creating a new CRC tree
Opening filesystem to check...
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: cannot open file system
# btrfs-image /dev/sdc image
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
ERROR: open ctree failed
ERROR: create failed: Success
# btrfs-select-super -s 1 /dev/sdc
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
Open ctree failed
# btrfs rescue super-recover -v /dev/sdc
All Devices:
        Device: id = 1, name = /dev/sdc

Before Recovering:
        [All good supers]:
                device name = /dev/sdc
                superblock bytenr = 65536

                device name = /dev/sdc
                superblock bytenr = 67108864

                device name = /dev/sdc
                superblock bytenr = 274877906944

        [All bad supers]:

All supers are valid, no need to recover

EDIT:

I just found btrfs-zero-log. It’s in btrfs rescue zero-log - but it didn’t work either:

# btrfs rescue zero-log /dev/sdc
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: could not open ctree

I’ve also asked about it on Stack Exchange:

I hear you.

Similar experience here in my brief foray into butter fs, when it fails it fails big time, unrecoverable file system implosion in my case.

There is a reason it was banished from RHEL.

Wasn’t that RHEL exclusion 5years ago or something?

It is my understanding that it is resilient if you are using its raid10 capabilities. With a single device, not that much.

More like 1 or 2 I think.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.