Hello,
I have a problem with KDE Dolphin file manager: It hangs when I try moving files between my local system (hosted on NVMe SSD [Btrfs]) and NFS v4.2 share on local network (1Gbit) (backed by debian 11 on ZFS on SATA SSDs).
What I mean by hangs is that when I try moving very large file(s) I cannot use it - I can’t open new window, I cannot open new tab or even open the filemanager settings.
Other applications running on the local system are reponsive.
Are there any settings I could change in kde/dolphin/nfs to prevent it from hanging on huge file transfers?
While I can’t provide an answer to this I’d echo that I’ve observed (in current version from debian testing) the same behaviour.
It’s not recently changed to be this way and now I search web for it I see other reports. I don’t do this often enough as part of an important workflow that I really thought about it before, and perhaps I should have.
to be specific
copy to a system mounted nfs share - hangs in this way (at least until it’s done)
copy to a smb share it dolphin accessed by ‘network’ - has normal UI behaviour.
if I were to test further i’d see if dolphin acts the same as nfs, when a smb, sshfs is mounted by the system fstab. if it were bad with all three that suggests it’s accessing something it expects to respond like a local disk, that remote just can’t keep up with (sync maybe).
as i have these fs commented out in my fstab perhaps i’ll try that.
hate to say this but I’ve always found how the free desktops handled network files to fall short.
2 Likes
So is it more that the app locks itself during transfer, or the system as a whole hangs?
Like, could it be a poorly threaded program?
And is it just when the target is bound like that? So like, with NFS.
Does it do the same when moving over Samba?
2 Likes
I would be willing to bet that the NFS options are not optimized on the client and that there are not enough threads running on the Debian host machine.
I get this occasionally on my system when writing large (gigabytes) files to the NAS because it is a raspberry pi 4 and it throttles, even with two fans and a heatsink. Once the system is max out to the settings for the NFS server on the host, or your settings are poorly optimized, you get this.
Keep in mind that NFS is extremely chatting and verbose and if you are running the normal default options (especially sync, and atime), all of that has to be written, updated locally on the host, communicated to the client, and then acknowledged by the client before it writes the next change (also updating any additional clients that are on the system).
You also don’t mention the system specs of the host system. If you want a cursory evaluation, post your NFS server config (optimizations) and also your client mounting options.
I know it has been a long time, however:
So far I discovered that:
Copy/Move operations are really fast at first because the remote NFS server running ZFS caches everything into RAM, once the RAM write cache fills up everything is sluggish
When the copy operations are going on everything is responsive… so long it’s not using whatever overengineered bug ridden libraries KDE folks came up with. As long as given application is not using the dumpsterfire called kio or kf it works fine.
When I open dolphin and try navigating to some directory in my $HOME while the NFS server is unreachable (for example when I managed to put my laptop to sleep [not easy on linux] and opened it somewhere else) it just hangs indefinetly. CLI utilities, my poorly written go/ts/java/rust applications, even chrome, none of them have any issues.
I have to open terminal and do sudo umount -l /mnt/* and then kill dolphin to unhang it… this issue is even more infuriating when we take into account that no new dolphin window/instance can be opened while the other one is “running”.
I dont understand why dolphin tries to open anything under /mnt/ when I navigate to completely different location.
Speculation:
My current conspiracy theory is that whoever wrote dolphin assumed that kio/kf will be working correctly and there probably is some as per documentation non-blocking function, however due to how buggy kio/kf is it’s actually blocking to the point where access to one filesystem causes it to somehow touch all mounted filesystems, in which case if even one of them is in a broken/blocked state kio/kf will just wait… instead of you know, giving/doing the thing you asked for.
As a sidenote - about a month ago I think I ran into intellij hanging when the nfs mount was either over laggy connection or in a broken state, however it was a one time occurence so I’d have to do more digging.