> On Nov 10, 2023, at 3:30 AM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote: > > On Fri, Nov 10, 2023 at 3:20 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: >>> >>> On Fri, 10 Nov 2023 at 01:37, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >>>> >>>>> On Nov 9, 2023, at 7:05 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: >>>>> >>>>> On Thu, 2 Nov 2023 at 10:51, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: >>>>>> >>>>>> Good morning! >>>>>> >>>>>> Does anyone have examples of how to use the refer= option in /etc/exports? >>>>> >>>>> Short answer: >>>>> To redirect an NFS mount from local machine /ref/baguette to >>>>> /export/home/baguette on host 134.49.22.111 add this to Linux >>>>> /etc/exports: >>>>> >>>>> /ref *(no_root_squash,refer=/export/home@134.49.22.111) >>>>> >>>>> This is basically an exports(5) manpage bug, which does not provide >>>>> ANY examples. >>>> >>>> That's because setting up a referral this way is deprecated. >>> >>> Why did you do that? >> >> The nfsref command on Linux matches the same command on Solaris. >> >> nfsref was added years ago to manage junctions, as part of FedFS. >> The "refer=" export option can't do that... > > Where in the kernel is the code for the refer= option? I'd like to get > some of my students to contribute support for custom NFS ports. IIRC supporting ports is one thing we can't do right now because the mountd downcall interface is text-based, and its parser can barely handle "refer=", let alone specifying a port. Our plan is to replace the mountd downcall with a netlink protocol that Lorenzo is working on, and then it would be very straightforward to add a port to each target location. But getting to a mature netlink implementation will take a while. > I would seriously suggest keeping it for "simple" use cases. We don't have any specific plan to remove support for the refer=/replica= export options. Deprecated (not "depreciated") simply means we are in the process of moving to something better for everyone. So don't build on the old stuff. However neither you nor Cedric have given a clear reason why you can't use nfsref other than "Debian won't build it for us". > nfsref(8) has ZERO deployment outside RHEL&RHEL clones Not anything upstream can control. We can help Debian with packaging concerns, but they haven't brought any to us. >> and FedFS has gone >> the way of the dodo. > > Why did that happen? ;( Complicated to set up (because true FedFS requires LDAP) and no interest from the user community. pNFS covers the use cases for referrals as far as people have needed it to. There has been no demand for it. Please do not confuse FedFS with support for referrals and replicas in the NFSv4 protocol. The latter are not going anywhere. >>> The configure switch in nfs-utils to build it is OFF by default, >> >> You're talking about >> >> --enable-junction enable support for NFS junctions [default=no] >> >> Perhaps that default should change -- it's been part of >> nfs-utils for five years now. However, that drags in >> dependencies for the xml libraries... maybe someone thinks >> that's a hazard? > > I would consider it a hazard when the kernel support code drags in XML. Can you back up that opinion with some technical facts as to why an nfs-utils XML dependency is a problem? >>> and the >>> distribution maintainers refuse to enable it because it can be >>> "dangerous", or may be "experimental". I got many excuses why they >>> dont want to enable that damn configure option. >>> >>> Also, stable and oldstable Debian do not have it enabled either. >> >> This is an upstream mailing list. We can't answer for what >> Linux distributors decide to enable or not. >> >> I've never heard that it was a dangerous feature. If a >> distro maintainer has a concern, they should bring it to >> upstream. >> >> >>> Seriously, why was refer= in exports(5) depreciated? There is no >>> realistic replacement, unless you fix every damn Linux distro first. >> >> Again, all the RHEL based distros package nfsref, as far >> as I am aware. And as you found, refer= still works. It's >> simply not documented. > > Then please document it. You have real world users for that one, who > would be grateful if you don't pull away the floor under their feet. Let me underscore this: we're not removing the referral capability from the kernel. No one's feet are going anywhere. The administrative interface for this mechanism is going to change at some point. It's simply taken much longer than anticipated. And again, you are welcome to contribute patches for the man page. That's kind of the point of open source. You don't go around demanding support for yada or updates for such-and-such man page. You contribute them yourself if they are missing. >> If your distro has decided not to support referrals, there's >> not much we can do about that except gently suggest that you >> switch to a distro that properly supports them. > > You could turn on --enable-junctions by default. And maybe get rid of > the XML dependencies. It's not easy to get rid of the XML library dependencies because the junction information stored in the trusted.junction.nfs xattr is stored in an XML byte stream. To replace XML itself, we'd need to either invent a private serialization format for the junction information, or go with something else that adds a library dependency, like JSON or yaml. I don't see how that is a win. -- Chuck Lever
