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 > https://github.com/archlinux/linux/commit/b24ee6c64ca785739b3ef8d95fd6becaad1bde39 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 [1], 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 [2]. 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? Cheerio, Hauke [1] <http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf> [2] <https://www.spinics.net/lists/linux-nfs/msg75432.html> -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
