Bug ID | 1120426 |
---|---|
Summary | Scramble btrfs maintenance timers (RandomizedDelaySec for btrfs-scrub.timer) |
Classification | openSUSE |
Product | openSUSE Distribution |
Version | Leap 15.0 |
Hardware | Other |
OS | Other |
Status | NEW |
Severity | Normal |
Priority | P5 - None |
Component | Basesystem |
Assignee | bnc-team-screening@forge.provo.novell.com |
Reporter | wagner-thomas@gmx.at |
QA Contact | qa-bugs@suse.de |
Found By | --- |
Blocker | --- |
I have an Leap 15.0 KVM host with many Leap 15.0 clients. All use btrfs as root filesystem. Some days round midnight, I experience a severe sluggishness of the system. Turns out, all VMs start their regular btrfs maintenance tasks via systemd timers at the same time, namely midnight. Although each VM starts the btrfs-{balance,trim,scrub} with low priority (IOSchedulingClass=idle, CPUSchedulingPolicy=idle), this does not consider that other VMs also started their btrfs maintenance tasks. This imposes a high load on the disks and all VMs are barely responsive. There is a systemd timer option RandomizedDelaySec. If this was set to like 1 day for btrfs-scrub.timer (runs every month) and like 12h for other btrfs task (they run every 5 days), the VMs would stagger their btrfs-maintenance task and not clog the disks. Maybe RandomizedDelaySec can be added to btrfs-{balance,trim,scrub}.timers