On Wed, Oct 07, 2020 at 12:44:42PM -0400, Trond Myklebust wrote: > The problem that all locks etc are tied to the lease, so if you change > the clientid (and hence change the lease) then you need to ensure that > the client knows to which lease the locks belong, that it is able to > respond appropriately to all delegation recalls, layout recalls, ... > etc. Looks to me like cl_owner_id never actually changes over the lifetime of a mount even if you change nfs4_unique_id. > This need to track things on a per-lease basis is why we have the > struct nfs_client. Things that are tracked on a per-superblock basis > are tracked by the struct nfs_server. > > However all this is moot as long as nobody can explain why we'd want to > do all this. > > As far as I can tell, this thread started with a complaint that > performance suffers when we don't allow setups that hack the client by > pretending that a multi-homed server is actually multiple different > servers. Yeah, honestly I don't understand the details of that case either. (There is one related thing I'm curious about, which is how close we are to keeping clients in different containers completely separate (which we'd need, for example, if we were to ever permit unprivileged nfs mounts). It looks to me like as long as two network namespaces use different client identifiers, the client should keep different state for them already? Or is there more to do there?) --b.
