Hi Guys, There's a nasty bug in kio v5.85.0-1 which causes slowdowns when navigating folders in KDE-based applications. To illustrate the problem, I have attached[1] a video-grab of Dolphin. As you can see, there's a delay of about half a second each time I try to enter a folder. The exception was in the first (AAAAA) case, where it took several seconds! The problem also becomes obvious towards end of the video when it walks back through the folders to the beginning. (You can see how slowly the folders are changing in the titlebar of the window, next to the mouse cursor.) I wish this problem was Dolphin-specific. Unfortunately that's not the case as it happens in other KDE applications (e.g. Gwenview and the File Open/Save-As windows while using Google Chrome) as well. Downgrading to kio v5.84.0-2 solves the problem. As you can see in this[2] forum thread, it has worked for at least one other person as well. So, whatever code changes were made in v5.85.0-1, I'm sorry to say that they need to be revised/reverted. Links [1]: https://drive.google.com/file/d/1IFjP0I6g9ildCx3eQEqvrGcCvOfx5L9x/view?usp=sharing [2]: https://bbs.archlinux.org/viewtopic.php?pid=1991655#p1991655
*** This bug has been marked as a duplicate of bug 442010 ***
(In reply to Antonio Rojas from comment #1) > > *** This bug has been marked as a duplicate of bug 442010 *** I'm not so sure that they're the same bug. I wasn't having problems opening/viewing any files. It was only the folders/directories that were causing lockups.
This is no duplicate! In my case, this bug is even slowing down opening folders for 8 secs (!!) each (!!) time!
I also experience this (very annoying) behavior on one of my Arch Linux installations. However, I have a second Arch installation on the same machine, that's not affected by this. Both installations are up to date (kio 5.86.0). I just installed plasma-desktop and dolphin in a fresh Arch VM (using the official images [1]). The issue does not occur there - all folders open instantly. So I believe this is not caused by kio itself, but by some system-wide configuration setting or maybe a separate package that somehow interferes with kio. I'll do my best to find out what's causing this. Links: [1]: https://gitlab.archlinux.org/archlinux/arch-boxes/-/jobs/34904/artifacts/browse/output
Thanks for doing that good research. Before going any further, just remember that downgrading to kio v5.84.0-2 solves the problem. That means there had to be a coding change between kio v5.84.0 and kio v5.85.0 which is responsible for this bug (even if kio isn't directly to blame). If the developers can determine which line(s) of code are causing it, they can then decide whether to roll them back or go looking elsewhere (as you're planning to do).
I was wondering about that, too, so I had a brief look at the commits between v5.84.0 and v5.85.0 [1], but I'm not experienced enough to find anything relevant there. Maybe I'll ask on Matrix/IRC if one of the developers can give me some advice. Links: [1] https://invent.kde.org/frameworks/kio/-/compare/v5.84.0...v5.85.0
I had some time today and did a git bisect to narrow this further down. It was introduced by kio commit 7de9c2e3 [1] Anyone who is affected by this: Do you use some kind of disk-encryption? I have two LUKS2 encrypted partitions mounted as / and /home on my affected installation. The unaffected installation doesn't use disk-encryption. Links: [1]: https://invent.kde.org/frameworks/kio/-/commit/7de9c2e34fb7f25e49437b269e7919aa923f362a
*** Bug 443370 has been marked as a duplicate of this bug. ***
bug 443370 adds an important information: This seems to be caused by certain fstab entries, namely "noauto". Commenting out entries with "noauto" in my /etc/fstab brings the file browsing speed back to normal. Thanks @Michael42
Yes, indead only editing fstab did the trick. No mount/umount was done. Should be easy to test.
I did some more tests. It seems that "noauto" isn't the problem, but entries with "UUID=" or "LABEL=". I was able to reproduce the issue with the following fstab entry: LABEL=foo /foo ext4 defaults 0 0 If I attach a device that has a partition with label "foo", the issue doesn't occur. This is also the case for "UUID=" entries. So, all in all this happens for fstab entries with "UUID=" or "LABEL=", where the corresponding device is not present. I suspect this is caused in the block starting at line 135 in kmountpoint.cpp [1]. If the device is not present, blkid cannot find the real device name, so maybe this requires an additional check beforehand. Links [1]: https://invent.kde.org/frameworks/kio/-/blob/7de9c2e34fb7f25e49437b269e7919aa923f362a/src/core/kmountpoint.cpp#L135
In kmountpoint.cpp blkid_evaluate_tag() is called without using the blkid cache (defaults to: /run/blkid/blkid.tab). I don't know how to implement this, but if it is necessary to evaluate all devices in every file browsing step, using the blkid cache would not only fix this problem, but might speed up file operations in general. After looking at util-linux/libblkid/src/evaluate.c [1] I was able to work around this problem, by setting "EVALUATE=udev" in /etc/blkid.conf The default is "udev,scan", so the scanning seems to cause the delay. Links [1]: https://github.com/karelzak/util-linux/blob/master/libblkid/src/evaluate.c
*** Bug 442726 has been marked as a duplicate of this bug. ***
*** Bug 443491 has been marked as a duplicate of this bug. ***
I am also experiencing this issue on Debian Testing and asked about it here (as I couldn't find this bug report): https://unix.stackexchange.com/questions/672885/large-delay-on-switching-directories-in-dolphin/673347#673347 And indeed I have /etc/fstab entries with UUID= of external drives that are not plugged in at the moment and indeed commenting out those lines makes dolphin as fast as it should be again.
I have changed my LABEL entries to /deb/s** ones, but I don't yet see a great change
I forgot. I didn't change UUID partitions (that is / ). It is not a risk? And how should I know the right "place" of / ?
(In reply to Duns from comment #17) > I forgot. I didn't change UUID partitions (that is / ). It is not a risk? > And how should I know the right "place" of / ? Changed / as well. But I still notice some slowliness...
@Duns: I don't recommend changing fstab. For me the best workaround so far is the one mentioned in comment 12: Create the file /etc/blkid.conf if it doesn't exist and add the line EVALUATE=udev
(In reply to Sebastian from comment #19) > @Duns: I don't recommend changing fstab. > For me the best workaround so far is the one mentioned in comment 12: > Create the file /etc/blkid.conf if it doesn't exist and add the line > EVALUATE=udev Yes, @sebastian, this seems really fix the problem. Thank you very much
Created attachment 142634 [details] 0001-KMountPoint-Reuse-blkid-cache.patch When reusing the blkid cache (see 0001-KMountPoint-Reuse-blkid-cache.patch), the speed improves, but there's still a noticable delay when fstab contains entries with unavailable LABEL/UUID devices.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/608
Thanks for the thorough investigation.
Git commit 221a94a66c4d2f6e4f2dc938ee8a63a6ca739477 by Ahmad Samir. Committed on 21/10/2021 at 16:12. Pushed by ahmadsamir into branch 'master'. KMountPoint: revert to parsing /dev/disk/by-{uuid,label}/ manually Apparently libblkid is causing some performance issues when resolving UUID/LABEL tags from fstab when the device that has that UUID/LABEL isn't present. Parsing /dev/disk/by-* is more basic, since it's a simple check resolving some symlinks. Thanks to the users in the bug report for the investigative work, because personally I couldn't reproduce the problem on my machine no matter what I tried. FIXED-IN: 5.88 M +1 -2 CMakeLists.txt M +2 -3 src/core/CMakeLists.txt M +1 -1 src/core/config-kmountpoint.h.cmake M +4 -14 src/core/kmountpoint.cpp https://invent.kde.org/frameworks/kio/commit/221a94a66c4d2f6e4f2dc938ee8a63a6ca739477
*** Bug 444786 has been marked as a duplicate of this bug. ***