On Mon, 27 Apr 2020 19:25:59 +0100, Leonidas Spyropoulos via arch-general wrote:
On 27/04/20, Hauke Fath wrote:
Re-reading, this is an Arch decision -- what is the rationale? Can anybody point me to a related discussion?
It's not, it just defaults to "Y", see patch in
Defaulting to "disabled" strikes me as heavy-handed.
From my experience, of running a few dozen nfs clients over more than fifteen years, at network speeds from 100 MBit clients / 1 GBit server to 1 GBit clients / 10 GBit server, the real-world relevance of ip fragment counter overruns is debatable. From a general background of transmission errors , the effect does not seem to stand out. FTR, we are running nfs through a filtering router, and found udp transport to be much more robust in the face of router outages.
So, to summarize:
The kernel nfs developers have deprecated nfs over udp in late 2019, AFAICS without much debate, and without any announcement outside the developers' mailing-list . So far, so unspectacular.
The interesting question is whether Linux distributions (Arch) should import this kernel change uncritically, and dump it on their unsuspecting users, without so much as a warning.
Given nfsv3 defaults to tcp, the "protect the innocent / think of the children" argument does not fly: When the admin wants to use nfs over udp (whether she chooses, or has to), she has to actively configure the mount, and take responsibility. In this light, disabling nfs over udp in the kernel seems patronizing to professional admins.
My question is: Where should I take the issue for further discussion? Is this mailing-list the right place? A forum group? Should I file a bug report?
 http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf  https://www.spinics.net/lists/linux-nfs/msg75432.html