> On Jan 11, 2024, at 10:06 AM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote: > > On Wed, Jan 10, 2024 at 4:11 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >> >> In most of these cases, the use of alternate ports has been >> superceded in the past 20 years. > > From a viewpoint of university hosting, HPC environments and pretty > much everything else I've seen, that statement is FAR from reality. > This even gets worse in Germany, Europe and Asia (not US of course, > you're hogging public IPv4 addresses), where we have IPv4 address > shortage, lots of NAT, and only a small amount of IPv6 (except Asia). > In all these scenarios you have NFSv4 connections all over the port > numbers, and not only 2049. > > Also, reality is, storage virtualisation for NFSv4 on the outgoing > side is typically done on the port level, and not IP address level, > e.g. many servers behind NAT, and NAT then translates the accesses to > the NFSv4 server into a single IPv4 address with different ports > (because of address shortage). And because of convenience, the NFSv4 > servers start with the same port number as used by NAT on the > outside... > > Short: Non-2049 port number are the not a "corner case" Well that's very nice, but this is the first I've heard of these requests and use cases. Telling me my lived experience is "far from reality" is not a good way to get your feature into our code base. And it's really not on point, unless your only point is to tell me how wrong I am. I will repeat, yet again: a. Linux NFS /does/ support alternate ports, but there are bugs b. We /do/ have a plan to support alternate ports in NFSv4 referrals c. We currently don't have the resources to focus on the parts of that that will be a heavy lift. But we will get to it eventually. d. To get your needs prioritized, send patches. You guys clearly do not know what else is on our plate, nor do you understand how few there are in the Linux NFS community. We think that good security, interoperability, and performance are the top priority, and dealing with bugs and regressions is up there as well. If this feature is important to the HPC community, they should fund a software consultant to implement what you need and work with us to merge it. That is the way open source works. That kind of technology transfer has worked for many many years. Since that has not happened in the past two decades, I think I am correct to assume that alternate ports are, in reality, working well enough for that community already. If you're simply going to demand that we implement your favorite feature without offering user stories or use cases or patches or any other context or help, then we will treat you like trolls. Because honestly, guys, you are acting like trolls. -- Chuck Lever
