Bug 442106

*** 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. ***