http://bugzilla.opensuse.org/show_bug.cgi?id=1063638
http://bugzilla.opensuse.org/show_bug.cgi?id=1063638#c53
Richard Brown
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... -- You are receiving this mail because: You are on the CC list for the bug.