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@gmail.com [mailto:purkaitabhinandan@gmail.com] Sent: Wednesday, August 19, 2026 9:06 PM To: devel@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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org