STEPS TO REPRODUCE 1. Create an empty file named test.txt on the Desktop or wherever 2. Try to delete it either via GUI or using kioclient5 move "the_filename.txt" trash:/ OBSERVED RESULT 1. Screenshot 1 shows and 1-3 minutes pass while waiting for something to happen 2. Screenshot 2 happens - 5 seconds up to 1 minute pass waiting for progress 3. File is deleted This happens also with VS Code which seems to use kioclient on KDE for deleting files, only without the notification showing but instead the VS Code own progress bar showing. EXPECTED RESULT Immediate deletion of file, just as rm does SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.16.16-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz Memory: 7,6 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 ADDITIONAL INFO I was chatting on the KDE Chat with someone about this and when I launched with the appropriate env variables to produce log it appeared stuck at some Qt function and we said that it is possible to be a Btrfs issue. Chatted with Btrfs and they said they fixed some such bug but after updating the Linux kernel bug stays. Before opening an official issue with Btrfs I want to get official statement from KDE that it's not a kioclient bug. I don't want to send Btrfs devs to chase Unicorns.
Created attachment 147843 [details] Screenshot 1
Created attachment 147844 [details] Screenshot 2
Еxcerpt from the Btrfs chat: Me: "Well i've tried trash-put and it seems to consistently do the deletion either immediately or no more than 5 seconds, usually instantly. kioclient5 on the other hand sometimes takes 3 minutes, sometimes 1 minute, sometimes 10 seconds, not less than 5 seconds for sure." Btrfs developer: "I can think of several ways to get those symptoms but they all involve heavy activity from background processes, snapshots, or mounting without noatime (pick any two)" Btrfs developer: "ok, so I was able to get 'kioclient5 move test.txt trash:/' to take over a minute" "during which it was running baloo_file, kioslave was calling fdatasync(), and something was running 'ldconfig -v' fdatasync() is probably unnecessary for trash files but maybe kio doesn't regard that as a special case" "ldconfig -v does run for minutes, it calls fsync() hundreds or even thousands of times" "so TL;DR moving a file to trash really does make KDE do enough work to keep a fast disk busy for minutes". Not sure if that's also what causes the same problem for me.
When deleting a file the process "kioslave5 /usr/lib/qt/plugins/kf5/kio/kio_t~/user/1000/plasmashellMrqIGz.28.slave-socket" has high Disk Read between 1 MB/S and 10 MB/S. Not sure why it behaves that way.
I think BTRFS is not the cause. I have the same issue on EXT4. From my experience it's related to operations that should take only a short time, e.g., deleting (or more precisely moving) a file/directory with the size of a few kilobytes. I tried it now on a few directories (100MB each) and saw something interesting: Moving them to trash should have taken less than one second, but it took approx. 30s; how this was achieved is of interest: 1. Select 3 directories, press Delete key 2. Notification status appears. It is in the indeterminate state (back-and-forth animation) 3. Few seconds later: Two directories disappeared in Dolphin 4. Notification switches to 1/3 state 5. Seconds later: Switches to 2/3 state, followed by 3/3 6. Third directory disappears from Dolphin I repeated this for different directories, where it worked as expected (although still quite slow). It's also not consistent for me. Sometimes it works, sometimes it doesn't. Maybe it's a weird concurrently bug somewhere? Plasma 5.24.4, Frameworks 5.92.0, Kubuntu 21.10 (via kubuntu-backports)
AFAIK, there is nothing in KIO code that would run ldconfig at all; so my suspicion is that since it's ldconfig and fdatasync() that there were system updates being installed in the background while the copying was being done, shared-mime-info runs fdatasync as part of its installation steps, see: https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/1f7683bfcbecbeffa802a1c361e1842db2fff4f8 ; so that dev's experiment results were skewed by that, I think. I don't know much about Btrfs, but that is just another data point. Note that if the files being deleted are on a partition other than /home/, it could be that trashing them is moving them to /home/<user>/.local/share/Trash; but of course that doesn't explain why deleting a single text file would be slow....
In my case, I'm deleting them from the Desktop which is located on the same @home subvolume (mounted on /home). Which is located on the same Btrfs filesystem on the same partition.
I experience the same issue with BTRFS. I want to add, that I'm also using LUKS disk encryption, but I'm not sure if this is related at all. Moving files to trash take several seconds for me, sometimes even longer. When using XFCE's file manager Thunar test wise, the deletion process finishes almost immediately. The trash folder is in the same BTRFS subvolume as the deleted files. Operating System: Manjaro Linux KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.15.59-1-MANJARO (64-bit) Graphics Platform: X11
I've reinstalled and switched distribuitions and this doesn't seem to happen on Kubuntu 23.04. Does it still happen for y'all?