https://bugs.kde.org/show_bug.cgi?id=480665
--- Comment #2 from tagwer...@innerjoin.org --- I'm afraid I'm not getting the same. I tried a similar test, a 2.2 GB video file copied over USB-A to a stick. I did the copy with "cp" and ran iotop to see how quickly the data was actually being written. Caching makes following the size of destination file confusing... I tried with and without baloo running and with baloo with a constrained amount of RAM (when it is run with "systemctl --user start kde-baloo", which limits RAM usage to 512 MB) and without (if you stop and restart Baloo with "balooctl disable" and "enable", you don't get that limitation). I saw no variation in speed. I presume you are not indexing the USB Stick? If you had that set up (somehow), that might possibly have an impact. Baloo would get notifications that the file had been updated and would repeatedly try to index it. In passing I noticed a couple of things that did make a difference to the write speed: If I watched the file "arrive" in Dolphin, the thumbnailing process was busy. I presume it also watches for file changes as Baloo does and repeatedly generates a thumbnail for it. If the copy was slow, then the thumbnailing load was higher. I was able to copy quickly on a newly rebooted machine. However if I accessed the USB from a KVM guest it was slow. If I unmounted the USB from the guest and went back to the host and tried again from there it was still slow, with a transfer speed of between 4 to 8 MB/sec (!). Even in this setup (testing from the VM guest), I didn't see a variation correlated to whether Baloo was running or not... This was with Fedora on the host - and an older Plasma/Frameworks 5.27.8 and 5.109.0 -- You are receiving this mail because: You are watching all bug changes.
