I don't know what happened, but I just logged into my system and
deleted some unused files in my home directory. Just some directories.
Suddenly everything on my system became read only. While rebooting I
think I saw messages like:
"BTRFS Error"
I booted into a live environment to restore my snapshots, then while
mounting the BTRFS root partition I got:
mount: /mnt: wrong fs type, bad option, bad superblock on
/dev/mapper/dm_crypt, missing codepage or helper program, or other
error.
Are you sure you are opening the right LUKS device in the live environment? Is the LUKS device readable (e.g. just using "cat /dev/mapper/dm_crypt > /dev/null")? (Does its size look right, e.g. in "lsblk -p"?) Do you get any read errors in dmesg (for NVME / SAS / SATA)? If you pipe your direct partition read through "pv -arb" ("pv -arb /dev/mapper/dm_crypt > /dev/null") (or another cat-like tool that shows the data rate), does it look reasonable?
Saving a binary image of your device would be a good first step — if the device is still readable.
I don't know what to do, my system won't boot.
Why is BTRFS so unstable ?
What makes you so sure that this is a Btrfs problem, as opposed to a SSD or hard drive failure or a RAM failure causing data corruption?
(Were there no other errors before the Btrfs errors in "dmesg"?)
While data loss of any kind is (understandably) frustrating, claiming that Btrfs is “unstable” is plain wrong and unhelpful and it is unlikely to motivate Btrfs experts to chime in and help.
:-/
(For example, I have been using Btrfs on all my systems since ~2010 and Btrfs RAID5/6 setups since ~2016. All I can say is that it has been perfectly stable in my case, saving my data many times over as my poor choice of SMR disks kept backfiring on me.)
Please don't tell me to erase everything and start again. that is not feasible.
Is there any other way?
A few suggestions:
0. Take a binary backup of your Btrfs device, if it’s still readable.
1. Check your RAM. Does the machine have ECC? You may want to give it a few hours of memtest, no matter what.
2. Check your SSD / disk whether it’s reading at a reasonable pace and showing nothing suspicious in "smartctl -A" and "dmesg".
3. Then there are a few tools (see man btrfs-check, man btrfs-rescue, man btrfs-restore) you might want to try, depending on the situation. Some of them require help from Btrfs experts (at which point you may want to ask on their kernel mailing lists).
No filesystem can cope with failing hardware or human error (such as unintentional low-level writes into a partition). It’s always good to rule out these cases first, before suspecting the filesystem. (If there was a stability issue, large production setups (https://lwn.net/Articles/824855/) would most likely spot it first.)
Andrej
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
