Entire system becomes less responsive when transfering files over NFS share

General system Newbie
1

I have EndeavourOS installed on a Lenovo Laptop and am currently using KDE with wayland support as my DE. It’s been my daily driver for several months now but there’s one problem I’ve yet to sort out with it. Whenever I transfer files over the network, specifically to an NFS share, my system becomes unstable during the transfer. It’ll often freeze completely for several seconds at a time. It happens most often when I hover the mouse over any of the icons in the taskbar. I really don’t know how to diagnose this. I’ve tried different settings for the NFS shares with no real changes. Switching to autofs did make the problem better, but it still happens regularly. I’ve used iotop and btop and don’t see any bottlenecks other than the wifi transfer speed, but don’t know why one file transfer should affect every aspect of the system.

I don’t get the same problem on my desktops, servers, or even my Pi which is connected through 2.4GHz. The 5GHz connection to the wifi router is strong. The router is in view of the laptop. I don’t have packet loss, but there is a 2 ms jitter that the hardwired devices don’t have.

I should note that I also had the problem happen rarely with my Samba shares, but much much less often.

Any help is appreciated. Thanks!

2

Does it work better when using x11?

Edit: here’s lots of info: https://wiki.archlinux.org/title/Network_configuration/Wireless

1 Like
3

weird, does it happen with a different DE?

1 Like
4

Yes, it does. It seems individual programs like my file browser will get slow, but the rest of the system seems fine. This is the behavior I expect on Wayland. I really hope I don’t have to choose Wayland features over better NFS usage.

I should clarify it still happens on X11. Just less often.

I will check through that link. Thanks!

5

I’ve only tested with KDE. Mostly just with Wayland until manuel mentioned trying it on x11. It still happens on X11, but it happens less often.

6

Can you show the output of

pacman -Qs xdg desktop portal
1 Like
7

I am wondering if this is an issue with preempting kernel tasks. Default arch kernel uses voluntary preemption. Could be that full preemption mitigates your problem.

Try to set full preemption with a kernel commandline parameter: preempt=full
and see if that helps.

1 Like
8

Here it is:

$ pacman -Qs xdg desktop portal
local/xdg-desktop-portal 1.18.2-1
    Desktop integration portals for sandboxed apps
local/xdg-desktop-portal-kde 5.27.10-1 (plasma)
    A backend implementation for xdg-desktop-portal using Qt/KF5
9

Thanks. I was thinking maybe you had another xdg portal, but that wasn’t the case. That could’ve explained the issue.

1 Like
10

Thanks! Just added it and will reboot to try it out shortly.

11

Alright, thanks.

1 Like
12

Well, it didn’t help with the NFS transfer, but so far I’ve yet to have it happen with my SMB transfer, which is currently running a bit more than twice as fast as the NFS transfer was interestingly enough. It might be this and switching everything back over to SMB could be the answer to solving this issue. I originally moved to NFS because of transfer speeds.

After about an hour of playing around with both NFS and SMB with the command line parameter preempt=full I can now say that transferring both large files, like 90 GB, and several small files, like 7000 10k ish B, are both operating are a bit more than double the speed to the same share when shared with SMB.

This is unexpected, but it looks like it’ll solve my problem. I don’t know what’s wrong with NFS, but if SMB is now the better option I have no problem moving everything over to it.

13

Traditionally NFS is clearly faster than SMB, so maybe the NFS options are not compatible on both ends?

14

I’ve tried several different settings and so far nothing’s helped. My local network consists of a hard wired desktop running EOS with two NFS shares, a wireless pi running Debian with two NFS shares, a wireless printer server running Debian with one NFS share, a hard wired desktop server running Debian with two NFS shares, and a hard wired blade server running Unraid with 14 NFS shares. I share all my shares between every device and this laptop is the only one with any issues at all. I swapped from SMB to NFS several month ago and overall it has been much better than SMB. Since I primarily use the laptop it looks like I’ll be using both SMB and NFS going forward.

It really doesn’t make sense to me at all, and there’s no clear way for me to debug the problem. Nothing of note shows up in journalctl except for one time when the video card caused a hard lock, but I don’t believe that was related to this at all. Well… actually I think the freeze is what caused the video card to lock up, but that doesn’t really help diagnose it.

15

Maybe the selected NFS protocol version could cause some issue?
I’d assume Debian might be using an older version than Arch.

I have witnessed (years ago) this problem with incompatible versions with the client and the server. Then changing them to be compatible the communication was considerably better.
Because it was years ago, I can’t remember the details anymore, but I remember it was quite a simple fix.
But then again, it might not be the same issue as back then.

16

how old is that laptop? does it have an ssd?