To be clear, the NLM lock owner is a client generated opaque string. There is no guarantee that it is unique across all clients. I'm pretty sure the NFS4 owner is the same way. The pointer is unique within an instance of Ganesha because it is the pointer to the state_owner_t that describes a specific client lock owner, which is indexed by the possibly/probably non-unique lock owner opaque from the client PLUS the client's IP address (for NLM) and clientid (for NFS4). A clustered filesystem would need to add its own "client" or "node" identifier. HA failover traditionally relies on use of the NLM and NFSv4 state (lock and open) recovery mechanism to re-acquire locks from the failed node. With this, the recovery process need not know how the lock owners from the failed node are identified. Jeff Layton added functionality into cephfs to prevent conflicting state from being granted after a cephfs client fails until the Ganesha clients establish grace period. In some HA failover situations, it may be possible for the new node to indicate it is recovering a lock, and reclaim a lock that is still instantiated by the failed node (in this case, the failed node must not actually be failed, but perhaps is considered down because a client side network interface is down, or it could be a failback situation where the IP address for a failed node is being returned to that node after it recovers). FSAL_GLUSTER's clustering implementation technically leaves a window where a node has failed and taken it's lock state with it before Ganesha recognizes the loss of node and triggers grace period. During this window, a client could claim a conflicting lock from another node. Jeff can go into all of what he did for cephfs if you are interested. Frank

I'm actually not that familiar with cephfs filelocking code, but I believe the "owner" value that we pass down to the client is only significant to that particular MDS client session. When the server reboots and reclaims the lock, that value will change, but that's ok, as that new value will also be unique and only significant within the context of the new CephFS MDS client session. On Wed, 2019-05-08 at 08:46 -0400, Daniel Gryniewicz wrote: -- Jeff Layton <jlayton(a)poochiereds.net&gt;