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