Great, thank you !

On Thu, Jun 21, 2018 at 5:51 PM, Frank Filz <ffilzlnx@mindspring.com> wrote:
> I confirm that the clienid has the same value for different processes. Indeed it
> makes senses because they are on the same machine, going through the same
> nfs client (which mount the NFS) so this one always gives the same verifier and
> receives the same clientid from the nfs server. Thus basically with the FSAL
> distinguishing lock owner by (pid, host), lock_op can not be done if processes
> are on the same machine. I have to take a look at other FSAL to see how to
> implement that, or if you have some better advise, it is very welcome.

What we typically do for lock owners in the FSAL is use the pointer to the Ganesha state_owner_t as an opaque lock owner. This is guaranteed to be unique for each client side lock owner.

NFS lock owners are a RPC opaque value that is only guaranteed to be unique per client, Ganesha uses client host (for NLM) and clientid (for v4) along with the opaque to index it's state owners. The pointer to the state_owner_t is consistent for the life of a state owner.

Accessing any details of the lock owner and depending on them is unwise even though many client lock owners are easily decoded.

Frank