> On Dec 2, 2024, at 10:19 PM, Steve Dickson <SteveD@xxxxxxxxxx> 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
