Dolphin/Desktop slowdown during smb file transfer


if I transfer a larger number of files from a smb share to the local harddisk using Dolphin, the filebrowser (not just the source/dest tabs, all of them) and also the desktop become quite sluggish. Is that normal and if not, what logs do you need and what steps can I take to fix the issue.

It began roughly in the last two months, it was fine before, the hardware has not changed, I am on latest stable.

I also got problems using dolphin + smb and large number of files … This with KDE on various distributions. Now, I use terminal mount and rsync it doesn’t solve the source issue but it does the job.


1 Like

Thank you, but my main issue is the UI getting unresponsive (file transfer could be faster, too, so that is good news nonetheless).

Sounds good, but if I don’t have swap memory?

CPU MHz:                         3407.022
              total        used        free      shared  buff/cache   available
Mem:           15Gi       1,9Gi       161Mi       133Mi        13Gi        13Gi
Swap:            0B          0B          0B
anthony     240536  8.5  0.1 105552 19116 ?        R    17:33   0:18 [kdeinit5] file local:/run/user/1000/klauncherJLoBCt.1.slave-socket local:/run/user/1000/dolphinJPoCAi.54.slave-socket
anthony     238316  5.3  0.1 105716 19244 ?        S    17:27   0:31 [kdeinit5] file local:/run/user/1000/klauncherJLoBCt.1.slave-socket local:/run/user/1000/dolphinGwkQyC.46.slave-socket
anthony       1415  3.9  0.0 949168 12804 ?        S<sl 12:22  12:16 /usr/bin/pulseaudio --daemonize=no
root      238203 30.3  0.0   8044  3140 ?        Rs   17:27   2:58 /usr/bin/mount.ntfs /dev/sdc1 /mnt/DISK02 -o rw,nosuid,nodev,noatime,nls=utf8,fmask=133,dmask=022,uid=1000,gid=1001,windows_names
root         843  1.3  0.7 1971376 127248 tty1   Ssl+ 12:22   4:23 /usr/lib/Xorg -nolisten tcp -auth /var/run/sddm/{e91a9a81-89c9-4215-9aff-d75a28bcf2d8} -background none -noreset -displayfd 17 -seat seat0 vt1
anthony       1666  1.2  1.4 271985464 238644 ?    Sl   12:22   3:53 /usr/bin/dolphin -session 1015910f14d13a00015810480400000004071_1581048851_400132
anthony     240696  1.1  0.1 105412 18996 ?        S    17:33   0:02 [kdeinit5] file local:/run/user/1000/klauncherJLoBCt.1.slave-socket local:/run/user/1000/dolphinuoMGzc.60.slave-socket
anthony     240697  1.0  0.5 2189092 96916 ?       Sl   17:33   0:02 [kdeinit5] thumbnail local:/run/user/1000/klauncherJLoBCt.1.slave-socket local:/run/user/1000/dolphinFvRdFu.61.slave-socket
root         748  0.9  0.0   8016  3296 ?        Rs   12:22   3:00 /usr/bin/mount.ntfs /dev/sdd1 /mnt/DISK01 -o rw,nosuid,nodev,noatime,nls=utf8,fmask=133,dmask=022,uid=1000,gid=1001,windows_names

The slowdown started as I pasted from a second or third folder over the network. Max RAM consumption was 15%, max CPU load was 37% for /usr/bin/mount.ntfs as opposed to 22% for that process normally.

Application launcher menu and the File menu of Kate opened slowly and it took a minute or so from clicking “Save As” to actually opening the “Save As” dialog (apart from that it could be used normally), after file transfer had been complete, everything worked normal again.
Starting programs was slow but once they run, they could be used normally.

How do see that the source drive uses ntfs (in the log above I am copying from the remote pc to two different local ntfs drives)?

Actually, the source drive is an ssd (ntfs), so I can’t defrag it, and eliminating my last window would take too many bricks, never change a running system, at least as long as you don’t have to work with it directly.

The target drives on the Manjaro machine are also ntfs and almost full but this is no reason for the ui to get sluggish imho. I haven’t seem such behavior since I installed manjaro, so my assumption was that an update is to blame.

I see, thanks!

It was fine two months ago, hardware did not change, only Manjaro got updates, so I can’t accept that, sorry.

SSDs shouldn’t be defragged.

You propose to replace the OS on the remote computer where nothing of software or hardware has changed, while everything worked perfectly two months ago and the only thing that changed was Manjaro and free space on the local drives.

So it is the local file system, okay, but why does a slow harddisk affect desktop redraw/program UI? If it would just take longer to show a file dialog, that’s fine, but program redraw or opening the app launcher should not be affected at all, especially since Manjaro is on a separate ssd with the usual ext4.

I will try iotop.

Try setting vm.vfs_cache_pressure=50 via sysctl, maybe it will help.

1 Like

Sorry for the late reply. Currently I have not enough free space to put this to the test and I don’t feel confident to change low-level settings, but I will keep it in mind. Thank you!