11:05 p.m.
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