http://bugzilla.opensuse.org/show_bug.cgi?id=1063638
http://bugzilla.opensuse.org/show_bug.cgi?id=1063638#c54
--- Comment #54 from Oliver Kurz
Hopefully there will be progress, since it's like 1/2 of year from the report of the bug and 0 progress
The predecessor is https://bugzilla.opensuse.org/show_bug.cgi?id=1017461 so actually the whole story is already older. Of course I am aware that there had been many more reports over different channels but my observation was that none of them really brought fixing the issue at hand any forward as too unspecific. This is why I want to help in this domain more and I think collecting the according information in according bugs can help. (In reply to Andre Guenther from comment #51)
Regarding the "stalling" issue: To be honest since i installed three systems with different versions of LEAP, different hardware and btrfs, i am under the impression that *every* installation suffers from this problem (more or less). Isn't that so?
Yes, I think you are right, e.g. see https://bugzilla.opensuse.org/show_bug.cgi?id=1017461 as a report against openSUSE Leap 42.2 . However since then changes to the different components of the systems - foremost the kernel itself - have introduced a lot of changes which should help. This is what was achieved in before and therefore it is very important to report in which product version (and potentially also which kernel) what problem was observed. Could you test the latest openSUSE Tumbleweed or openSUSE Leap 15.0? I already stated that I have troubles to find a scenario which can clearly reproduce the issue.
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 :-)
Can not confirm. I just tried that: * Installed a recent openSUSE Tumbleweed 20180605 x86_64 on LVM, encrypted root, 90 GB HDD, notebook hardware * Installed a lot of packages (full plasma session, servers, etc.), started yast2 * copied random data to hard disk, e.g. `for i in {1..1000}; do dd if=/dev/urandom bs=64M count=1 of=/tmp/out_$i.bin ; done` * started `btrfs scrub start /`, started snapper service * hard-rebooted the system with `magic sysrq-b` * system could startup without any problem observed so not as easy to reproduce as that :( (In reply to Gabor Katona from comment #52)
[…] The second is just as important but more general. A fundamental system component like a file system should NEVER eat up the CPU or render the system unusable in any other way.
I agree with all your points here.
Currently BTRFS is experimental, the sooner you accept it the faster you provide a solution: SKIP BTRFS for opensuse.
I guess you can achieve the same by disabling qgroups and snapshots. This is also easily possible from the installer. However, important features are missing then which you might want to have by different means, e.g. LVM including snapshot volumes and more backups including your own cleanup strategy for this. -- You are receiving this mail because: You are on the CC list for the bug.