http://bugzilla.opensuse.org/show_bug.cgi?id=1063638
http://bugzilla.opensuse.org/show_bug.cgi?id=1063638#c94
Joachim Banzhaf changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joachim.banzhaf@googlemail.
| |com
--- Comment #94 from Joachim Banzhaf ---
seems I was bitten by this, too for a long time.
Leap 43.3 with updates on a 8gb ram laptop with btrfs root fs on ssd.
Gui freezes for a long time (minutes).
Switch to console worked once. Could see btrfs-tra... at 100%
This time I could not stop the system before the battery was drained.
After reboot, system went to emergency mode.
Cpu at 100%, changing between btrfs snd mount of root fs
On previous occasions the stops were not so long and I always thought that is
some hardware related defect.
Now that I had the time, I read many forum posts and bugzilla comments, I know
it is not hardware but fs and there is no real solution, but to wait until the
process finishes.
For the decision makers: no, a fs that does this is not stable, even if there
is no data loss. A fs that needs substantial resources just to stay healthy is
crap.
I maintain linux systems for a long time (started with suse 6.x). I very rarely
have the need of going back to a previous system state. So despite it sounds
cool to have a feature that does this easily, it is not worth the trouble it
currently causes by far. And the reason why it does not happen on sles? My
personal experience says: because we run opensuse on our notebooks and so use
other fs where it matters: ext and xfs.
Hm, in the meantime it looks like the system has recovered: can I provide some
useful info?
--
You are receiving this mail because:
You are on the CC list for the bug.