How to recover from segfaulting btrfs ?

I am running latest Tumbleweed and latest btrfs(4.14.1).

Yesterday night,I left the system for a big update of 300+ packages, may be that included btrfs update too.Today morning, update was succefully-finished, but I felt slow response, ‘top’ showed btrfs @ 25% load and then come down,I rebooted cleanly. While going down, it was not normal and the system could not bring up login page.

The root file system is corrupt and an attempt to do, 'btrfs check --repair /dev/sda2 ’ ends in segfault. Just 'btrfs check /dev/sda2 ’ produces no segfault.I have tried in a ‘Rescue’ environment and booting to a Maintenance environment.On both occssions, repair attempt segfaults.

I have done quite an amount of re-search on recovery options,I have run ‘badblocks’ and then run repair.I have tried ‘mount -o recovery…’, ‘zero-log’ et all as suggested at different places, but no good.

Now my questions,

  1. Is it even possible to bring this partition (sda2-btrfs) to a working stage ? If possible,I want to put some effort there as complete re-install with later codec installation,MS font installation, font anti-aliasing, various networking and applications details are very painful.

I am comfortable with baisc command-line.

Thanks in advance to any help.

Not funny. Can you mount the btrfs filesystem when booting from an install medium?

@knurpht : No. It cannot be mounted even in a live environment. It looks like, I am condemned to re-install by btrfs ! :(. Thank you.

The definition of insanity is doing the same thing and expecting a different result. Try ext4 for all your filesystems instead of hybrid mix of xfs + btrfs.

Did you rule out hardware, like a failing HDD or SSD? What does smart report?

I see I’m not the only one. I had the exact same issue after updating yesterday. My system did not want to shut down normally, and when it finally did, it would not come back up. I too had btrfs check --repair end in a segfault, and I too just reinstalled. I just bought my SSD new in December, and I highly doubt it is the cause here.

So not only is the btrfs filesystem hosed, but also the btrfs check tool is not robust …

Not a Samsung SSD? No issues seen with an OCZ SSD here (MacBook3,1) up to kernel 4.15.0, on both my Tumbleweed systems (20180205) running mq-deadline (SSD) and bfq (HDD) for schedulers.

I have two machines, each with a Samsung SSD. My desktop is the one that tanked, but my laptop is fine so far. I can’t confirm this because my root partition was completely ruined and I had to reinstall, but my suspicion is that the scheduled btrfs balancing task occurred while I was shutting down, which might explain why my shutdown was not normal (and OP mentioned something similar happening). If that’s the case, then it might be possible for root filesystem corruption if you are unlucky enough to shut down when your system starts btrfs balancing.