9:39 p.m.
Hi Abhinandan,
On Thu, 20 Aug 2026 04:05:51 -0000, purkaitabhinandan(a)gmail.com wrote:
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?
We're on something older than you. We're on V5.9 with >160
cherry-picks/backports, mostly bug fixes.
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.
We're doing loosely clustered NFS-Ganesha but we don't expect this type
of change to work across online upgrades.
One limitation is that you can't change the value of Filesystem_ID
while NFS-Ganesha is up... or FSID_override either, I think.
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.
My plan is to pick a Filesystem_ID major for all exports for a site and
set the minor to be equal to the Export_ID. This seems to be a common
approach. I haven't thought through multitenancy, but my starting point
would be a tenant ID as major and continue with Export_ID for minor.
It is a nice and dumb approach... but needs to be carefully considered.
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.
Yeah, again, we've cherry-picked/backported to V5.9.
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.
I think it was this that stopped me from digging deeper:
#ifndef FIXME
return;
#else
/**
* More investigation/design is required to determine the best
* implementation for the remainder of this method. In the interim,
* Coverity complains that this is dead code because of the early
* return above. Hence the remainder of this method is ifdef'ed
* out to avoid the Coverity complaint.
*
* @todo: FIXME: make the rest of this work
*/
:-)
I think, after seeing this, and the lack of comments anywhere
describing how fs_ng is meant to be better, I cut my losses early
and decided to see if we could make something work using fs. That was
quite tricky... but now trivial with RecoveryBackendIPBased.
peace & happiness,
martin