On 7/14/25 9:31 AM, Christoph Hellwig wrote: > On Mon, Jul 14, 2025 at 09:24:20AM -0400, Chuck Lever wrote: >> On 7/14/25 2:30 AM, Christoph Hellwig wrote: >>> Add a mount option to set a clientid, similarly to how it can be >>> configured through the per-netfs sysfs file. This allows for easy >>> testing of behavior that relies on the client ID likes locks or >>> delegations with having to resort to separate VMs or containers. >> >> The problem with approaches like this is that it becomes difficult >> to manage multiple mounts of the same server. Each of those mounts >> really cannot have a different clientid. > > Having different clientids for multiple mounts from the same server > is the purpose and only reason for this option. 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). >> For testing, why can't you use the per-container clientid setting? > > Because having to create a container is a lot of effort when all > that is needed is just a mount with a different clientid. 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. If clientid= does get merged, though, what is your plan for an nfs(5) update? -- Chuck Lever
