On Wed, 2020-10-07 at 13:15 -0400, Bruce Fields wrote: > 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. It never changes over the lifetime of the nfs_client. If it did, we'd be inviting fun scenarios in which we end up conflicting with ourself over locks etc. > > > 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?) The containerised use case should already work. The containers have their own private uniquifiers, which can be changed via /sys/fs/nfs/net/nfs_client/identifier. In fact, there is also a udev trigger for that pseudofile, so my plan is (in my copious spare time) to write a /usr/lib/udev/nfs-set- identifier helper in order to manage the container uniquifier, to allow generation on the fly and persistence. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
