On Mon, Jul 14, 2025 at 10:47:54AM -0400, Chuck Lever wrote: > It would be helpful to explain exactly what test you are trying to do or > what bug you are trying to explore. I can't think of a way that the > current client code base would ever need to behave this way. So I assume > you are trying to test some kind of server behavior. If that's the case, > why not craft one or more pynfs test cases? (Or, maybe pynfs already > handles this case). In this case I test the performance of delegation recalls on the client, for which I need another client to trigger the recall. See the "use a hash for looking up delegation" series for the result. > Since this is for development testing (?) I am hesitant to endorse > adding it as part of the everyday administrative interface. Especially > since this will break things (on purpose, of course). I don't relish > having to support administrators coming to us complaining that some > unimagined future use case is not working with the clientid= mount > option. What use case would this break? It basically means that if you mount the same export multiple times, where at least one of the mounts has this option specified you don't share the connection and sb, but get a new one with a different client id. I don't see any good use case for that outside of testing, but I also don't see how it could create problems. > If clientid= does get merged, though, what is your plan for an nfs(5) > update? Add it and discourage the use. Which reminds me that the man page also needs an update for the tls key changes.
