| Summary: | Deleting files to trash with kio very slow | trash-cli and rm work correctly | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Lyubomir <liubomirwm> |
| Component: | Trash | Assignee: | David Faure <faure> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | a.samirh78, christ.derek, frapox, kdelibs-bugs, mrboese |
| Priority: | NOR | ||
| Version: | 5.92.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Screenshot 1
Screenshot 2 |
||
|
Description
Lyubomir
2022-03-30 12:06:54 UTC
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? |