On Mon, Jan 29, 2024 at 4:51 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
>
>
> > On Jan 29, 2024, at 10:07 AM, Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote:
> >
> > On Mon, Jan 29, 2024 at 3:14 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
> >>
> >>> On Jan 29, 2024, at 6:44 AM, Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote:
> >>>
> >>> On Mon, Nov 13, 2023 at 2:01 AM Cedric Blancher
> >>> <cedric.blancher@xxxxxxxxx> wrote:
> >>>> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
> >>>>>> 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:
> >>> [snip]
> >>>> Yeah, instead of waiting for NetLink you could implement Roland's
> >>>> suggestion, and change "hostname" to "hostport" in your test-based
> >>>> mount protocol, and technically everywhere else, like /proc/mounts and
> >>>> the /sbin/mount output.
> >>>> So instead of:
> >>>> mount -t nfs -o port=4444 10.10.0.10:/backups /var/backups
> >>>> you could use
> >>>> mount -t nfs 10.10.0.10@4444:/backups /var/backups
> >>>>
> >>>> The same applies to refer= - just change from "hostname" to
> >>>> "hostport", and the text-based mountd downcall can stay the same (e.g.
> >>>> so "foobarhost" changes to "foobarhost@444" in the mountd download.)
> >>> [snip]
> >>>
> >>> What would be the correct syntax to specify a custom (non-2049) TCP
> >>> port for refer= in /etc/exports ?
> >>>
> >>> Would this work:
> >>> ---- snip ----
> >>> `/ref *(no_root_squash,refer=/export/home@134.49.22.111:32049)
> >>> ---- snip ----
> >>
> >> Hello Roland -
> >>
> >> Although generic NFSv4 referral support has been in NFSD for
> >> many years, NFSD currently does not implement alternate ports
> >> in referrals.
> >
> > I know, but the question is about the syntax in /etc/exports. The idea
> > is to use the same syntax for other NFSv4 server implementations (like
> > nfs4j) ...
>
> We're planning not to support alternate ports via the refer= export
> option. Instead, we plan to add the ability to specify an alternate
> port via the "nfsref" command.
But that was NOT Rolands question. The question was which syntax would
work ('Would this work:'), as this is for other NFSv4 server software
such as nfs4j, which tries to be compatible with Linux.
>
> The refer= export option (that is, using this UI for setting up NFSv4
> referrals) has been experimental since it was introduced, and has a
> number of limitations that we hope to avoid by using "nfsref" instead.
The problem I see is that - if Linux nfsref gets fixed to include
custom ports - then it will take at least 3-5 years until this version
is readily available in ALL stable versions of all distributions.
Any improvements or fixes to refer= is available with the next Linux
kernel patch, and I'd be more than happy to pay $$$$ to customer
support to have such a patch backported to a stable branch.
>
> As an alternative, Solaris, for instance, does not use the /etc/export
> interface mechanism at all, preferring instead the "share" and "nfsref"
> commands. (though as far as I am aware, Solaris does not implement
> support for alternate ports in referrals either).
>
> Solaris has support for reparse points (as does FreeBSD). "nfsref"
> is supposed to be a mechanism for editing those, and theoretically
> reparse points were supposed to handle more than just NFSv4 referrals.
How would a reparse point with a custom NFSv4 port look like?
>
> Unfortunately I was never able to generate a lot of appetite in the
> Linux kernel community for implementing reparse points in our file
> systems. Our "nfsref" command is therefore somewhat limited.
Did you document this somewhere?
Thanks,
Martin
