Re: [nfs-utils PATCH] exports: Fix referrals when --enable-junction=no

[Chuck Lever III <chuck.lever@oracle.com>]

> On Dec 2, 2024, at 10:19 PM, Steve Dickson <SteveD@redhat.com> wrote:
> 
> Hey,
> 
> On 12/2/24 3:30 PM, Scott Mayhew wrote:
>> Commit 15dc0bea ("exportd: Moved cache upcalls routines into
>> libexport.a") caused write_fsloc() to be elided when junction support is
>> disabled.  Get rid of the bogus #ifdef HAVE_JUNCTION_SUPPORT blocks so
>> that referrals work again (the only #ifdef HAVE_JUNCTION_SUPPORT should
>> be around actual junction code).
> Why not just take the enable_junction config variable
> out of configure.ac as well?

It's not generally good practice, but I will break up your
sentence below to reply to each bit. There is something to
unpack in each part.


> If we want junctions/referrals (which are the same)
> IMHO...

Junctions and refer= are related, but they aren't
the same. As Scott demonstrated, a junction is a file
system object that stores NFSv4 referral information.
The "refer=" export option stores that information in
/etc/exports.

The common part of these two mechanisms resides in
NFSD, which turns that information into the response
to a GETATTR(fs_locations).


> on all the time...

We want "refer=" on all the time, yes.

Junction support has to be enabled manually. This is
because it depends on libxml2, which not every distro
wants to, or can, pull into its nfs-utils package.

That is in fact exactly how Salvatore is using this
option. The stable version of Debian's nfs-utils
package does not want libxml2, so junction support is
disabled there. But they /do/ want "refer=" support.


> Lets not be able to turn them off at all?

That would be nice, but it's not yet practical for
every distro to enable it.

I am told that Debian unstable's nfs-utils will
enable junction support, and has added the libxml2
dependency successfully.

We will get there eventually.


> Point being... if we are going remove 3 of the 4
> HAVE_JUNCTION_SUPPORT ifdefs... let get ride of
> all of them.


--
Chuck Lever