Bug 1111523 - Btrfs consume too much CPU resources and cause desktop freeze after zypper dup
Btrfs consume too much CPU resources and cause desktop freeze after zypper dup
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Jeff Mahoney
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2018-10-11 12:09 UTC by Yunhe Guo
Modified: 2021-06-25 07:02 UTC (History)
8 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Yunhe Guo 2018-10-11 12:09:50 UTC
If a Tumbleweed snapshot is big (hundreds of package updated, thousands of files deleted/added), after zypper dup and reboot, system will be very slow and not responding. In KDE, when I see desktop is freezing, I open task manager and found btrfs-cleaner or btrfs-transacti using 25% (100% of one core) of CPU resources.

Even I have a 4-core CPU, using up 100% of one core can cause desktop not responding.

I am using a Tumbleweed system installed in September 2017. Does new Tumbleweed installer have different Btrfs options that can solve this problem?
Comment 1 Zejin Xu 2018-10-16 09:28:51 UTC
Hi Yunhe,

How many snapshots do you have altogether? Could you attach the output of that list? (run command 'snapper list' in root will do)

Comment 2 Yunhe Guo 2018-10-16 09:50:52 UTC
I remember I have around 20 snapshots before. The Btrfs partition was 60 GB SSHD (more like HHD rather than SSD) and available space was 10 ~ 20 GB. Snapshots take a lot of space.

Just fully formatted the disk and reinstalled Tumbleweed yesterday. Maybe it will make a difference. Some Btrfs partition setup has been improvement but can only be effective after reformat partition.
Comment 3 Jeff Mahoney 2019-01-08 17:10:59 UTC
This is due to qgroups being enabled by default.  We have fixes coming for this but for now a workaround is to disable qgroups on that file system.
Comment 4 Wenruo Qu 2019-01-09 04:50:16 UTC
If it's all about snapshot deletion, I'm afraid the incoming qgroup improvement won't really help.

Most of my recent submitted patches are only enhancing qgroup + balance, while for subvolume delete, the subtree rescan can't really be avoided/delayed.
Comment 5 Jeff Mahoney 2019-01-09 12:09:36 UTC
The fixes you’re working on may not have an effect here but Mark’s probably will.
Comment 6 Stanislav Brabec 2019-09-30 18:03:02 UTC
Bug 1032027 is probably a duplicate.
Comment 7 Felix Niederwanger 2021-06-25 07:02:18 UTC

I'm noticing the same in like 1/4 times I update my Tumbleweed laptop. At some point, the system becomes highly unresponsive, dialogs freeze and you cannot do any meaningful work for like 1-2 minutes. Even typing bugzilla.opensuse.org within Firefox was not possible now. In all the cases when I observed this system unresponsiveness, there was a btrfs maintenance job running in the background, either a qgroup scan or a scrub.

Is there be a way to lower the priority of those maintenance job runs, so they appear to be less resource aggressive? I could see that this would be beneficial on pre-emptive desktop systems like laptops/desktops/workstations.
I think I'm not the only one who would prefer a more responsive system while background maintenance jobs are running over "let's freeze the system for a short amount of time and be done with it".
Saying explicitly on desktop systems, on servers the situation is different.