https://bugs.kde.org/show_bug.cgi?id=448451
Bug ID: 448451
Summary: ksysguard, the kde system monitor, makes wrong
assumption about block devices
Product: ksysguard
Version: unspecified
Platform: openSUSE RPMs
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: ksysguard
Assignee: ksysguard-b...@kde.org
Reporter: jwag...@computing.dcu.ie
CC: plasma-b...@kde.org
Target Milestone: ---
SUMMARY
KSysGuard 5.18.5 (version not in version list above) in openSUSE Leap 15.3
assumes device names such as /dev/nvme1n1p7 have a permanent device number
(major:minor) and only offers to monitor dm devices by their number, e.g.
/dev/dm-3, even though the device nodes created by openSUSE vary between
restarts, e.g.
* with 2 NVMe SSDs, the device minor assigned to them is sometimes swapped
* if a partition is added or removed from the first NVMe SSD, the device minors
for the partitions of the second NVMe SSD are incremented or decremented by 1
* LUKS crypt devices are allocated /dev/dm-* devices in unpredictable order,
presumably because all are set up with the same iter-time, leaving it to tiny
timing differences in which order the devices are set up
STEPS TO REPRODUCE
1. Set up a system with multiple NVMe SSDs and multiple encrypted filesystems
(my setup is described further below)
2. Add sensors to the KDE System Monitor for the backing devices of each
filesystem, for the full path from the direct device(s), over the dm crypt
devices to partitions and SSDs/HDDs.
3. Reboot every day and observe sensors
4. Add or remove a partition on the first SSD and continue step 3
OBSERVED RESULT
* Sensors for the NVMe drives sometimes report "error" as the minor device
number no longer matches.
* Sensors for dm devices are useless if organised on tabs for individual
filesystems as the the order op dm device numbers are random. Only a tab with
all dm devices in numerical order is somewhat useful.
* Sensors for partitions on the 2nd SSD permanently report "error" as the minor
device number no longer matches.
EXPECTED RESULT
The sensor browser for block devices should first branch into selection based
on any of minor:major, device name, device mapper alias, /dev/disk/by-id etc.
and only store one device selector with the sheet, e.g. the name
/dev/mapper/cr_home. On startup of ksysguard (or more often), the major:minor
device number currently associated with this name is determined and used for
obtaining sensor data (presumable from /proc/diskstats).
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: openSUSE Leap 15.3 default KDE installation
KDE Plasma Version: 20181130-lp153.2-8
KDE Frameworks Version: KDE Frameworks 5.76.0
Qt Version: Qt 5.12.7 (built against 5.12.7)
ADDITIONAL INFORMATION
* Asus B550-Pro mainboard with 2 NVMe SSDs and 2 HDDs
* / and more via btrfs subvolumes, btrfs on LVM on LUKS on /dev/md0p1 on md
RAID1 on /dev/nvme0n1p5 + /dev/nvme1n1p1 (set up with yast installer)
* 2x swap on 2x LUKS with volatile random key on SSDs
* /home with separate btrfs, btrfs on 2x LUKS on NVMe SSD partitions identified
with /dev/disk/by-id/nvme-... in /etc/crypttab (manual setup)
* /scratch with separate btrfs, btrfs on 2x bcache on 4x LUKS on SSDs and HDDs
(manual setup; yast would insist on putting LUKS on top of bcache, leaking
information on the size and frequency of access of cached objects)
* iter-time of all 9 LUKS containers manually reduced to avoid time outs during
startup
WORKAROUND
Write a script / systemd service that updates the files in
/home/*/share/ksysguard/ on login or startup before ksysguard loads these
configuration files.
--
You are receiving this mail because:
You are watching all bug changes.
