[arch-general] NFS "updates"?
hf at spg.tu-darmstadt.de
Wed Apr 29 11:38:11 UTC 2020
On Mon, 27 Apr 2020 19:25:59 +0100, Leonidas Spyropoulos via
> 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
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
More information about the arch-general