Great, thank you !
On Thu, Jun 21, 2018 at 5:51 PM, Frank Filz <ffilzlnx(a)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