On 2016-12-31 11:00, Richard Brown wrote:
Top-posting because I believe the information I'm about to share supercedes the majority of the other posts:
You can simply post without any quoted material ;-)
I'm shocked and somewhat disappointed that while someone linked https://btrfs.wiki.kernel.org/index.php/Btrfsck I cannot see that anyone cited the most important part:
In a nutshell, you should look at:
btrfs scrub to detect issues on live filesystems look at btrfs detected errors in syslog (look at Marc's blog above on how to use sec.pl to do this) mount -o ro,recovery to mount a filesystem with issues btrfs-zero-log might help in specific cases. Go read Btrfs-zero-log btrfs restore will help you copy data off a broken btrfs filesystem. See its page: Restore btrfs check --repair, aka btrfsck is your last option if the ones above have not worked.
Did you do all of the above before trying btrfs check --repair?
Well, I find that procedure too complex. One of the reasons I refuse to use btrfs. IMO, btrfs should have a single tool that automatically analyzes a btrfs filesystem and automatically decides on the best course of action, perhaps asking the user some simple questions. You mention, for instance:
mount -o ro,recovery to mount a filesystem with issues
But you need another running system to do that... and Leap doesn't have a rescue image anymore. The OP mentions having to use a Debian live image instead.
A lot of the horror stories I've seen regarding btrfs are due to misuse / abuse of btrfs far more than actual issues or bugs,
Well, you can not expect users to be knowledgeable about filesystem nuances, specially being btrfs that advanced and complex. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)