Comment # 53 on bug 1063638 from Richard Brown

(In reply to Andre Guenther from comment #51)

> The second one is very easy to reproduce:
> Wait until btrfs does it's 100% CPU utilisation thing (balance, trim,
> whatever), press the reset-switch and say goodbye to your filesystem :-)

I'm sorry, but that's nonsense.

While the load condition is reproducible, and I can confirm that pressing the
reset-switch during a high-load btrfs condition MAY make the filesystem
unmountable, but I have literally dozens of cases where following our
documented process [1] fixes such problems and ZERO where it does not.

Therefore there claims of dataloss are not valid and this second issue could be
considered Major (because of the disruption) but not Critical

Note it's my experience that the problems with high-load btrfs conditions are
often exacerbated by scrubs/balance/trims not being run often enough, therefore
having more of a mess to fix when they do actually run - Maybe the solution
should be to run them more often, such as via systemd timers so we can be sure
they run more often.

[1]
https://en.opensuse.org/SDB:BTRFS#How_to_repair_a_broken.2Funmountable_btrfs_filesystem