8:01 p.m.
Sorry I have not updated the Wiki with the latest supported version...
We switched to a model where we really only support the next branch at the latest level.
In truth, we will help folks several major versions back from that (currently 15.1 and
several versions back from that), but if someone hits a problem that seems like it might
have been addressed, we would ask them to try the latest version.
The major version number bumps whenever we (I) merge a significant feature patch.
RecoveryBackendIPBased should be a few versions back from 15.1, but definitely nowhere
close to 6.5.
Frank
-----Original Message-----
From: purkaitabhinandan(a)gmail.com [mailto:purkaitabhinandan@gmail.com]
Sent: Wednesday, August 19, 2026 9:06 PM
To: devel(a)lists.nfs-ganesha.org
Subject: [NFS-Ganesha-Devel] Re: Guidance: keeping `RecoveryRoot` inside an exported tree
via a nested export with `Access_Type = None`
Thanks Martin. The FSID_Override idea is the first thing I've seen that would actually
close the hole Frank mentioned, so I'm interested in how it goes.
Issue is we're on 6.5 and neither of the things you mention seems to be there. As far
as I can tell fsid_override is only parsed in `nfs_read_conf.c` from V15.1, and
`recovery_fs.c` doesn't reference `recovery_backend_ipbased` until V15.1 either,
nothing at V15. Neither string is in our binary.
So: which version are you doing FSID_Override on, next or a backport onto something
older?
Does turning it on change handles that clients already hold? We'd be enabling it under
live mounts, so I want to know whether to expect a round of ESTALE or whether it only
affects handles issued afterwards. If you haven't got to the negatives yet, that's
the one I'd look at first.
And how are you picking the Filesystem_Id per export? We create an export per volume,
dynamically, so I need something that generates them rather than a number in a config
file. Curious whether you're deriving it from something stable or just counting.
On RecoveryBackendIPBased, which release were you on when you used it?
If it only landed in V15.1 and you had it before then, you're presumably carrying a
backport, and I'd like to know, because we may end up wanting the same.
We hit the same problem, but solved it by patch rather than config since
6.5 gives us no option: we drop the client's source address from the recovery tag
entirely. Under a container network that address flips between the bridge and the VXLAN
interface depending on whether client and server share a node, so moving the server
rekeyed every client, not just the one that moved. Tags are stable across nodes now.
One more thing, do you remember what the fs_ng comments actually said, or what you ran
into? We've taken your advice and stayed on fs, but I'd rather know the real gap
than avoid it on reputation.
cheers,
Abhinandan
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org