Hi Daniel, Thank you for your reply. I've also tried with the client_id but it also has the same value for 2 different processes. So if the client_id and the opaque always have the same value (for 2 different processes), how can we distinguish the client? I've tried with this field so_owner.so_nfs4_owner.so_clientid Thank you. Viet On Mon, Apr 30, 2018 at 2:38 PM, Daniel Gryniewicz <dang(a)redhat.com <mailto:dang@redhat.com>> wrote: This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org <http://lists.nfs-ganesha.org>;. Hi. The client program ID in a lock owner is an opaque.  That is, it's not defined in the spec, and the server can't use it for anything other than a byte string.  The concatenation of the client-ID and the opaque part of the lock owner is unique, but the opaque part of the lock owner itself is not. That value only has meaning to the client. Daniel On 04/30/2018 08:18 AM, Tuan Viet Nguyen wrote: This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org <http://lists.nfs-ganesha.org>;. Hello, While trying to get more information related to the lock owner, I'm trying to get the client program id and realize that it always takes the same value (easy to do with a test program forking another process, parent lock a file range then the child locks another range). Is it something similar to the client process id that is stored in the client record structure? or any other suggestions? Thank you ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel(a)lists.sourceforge.net <mailto:Nfs-ganesha-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel(a)lists.sourceforge.net <mailto:Nfs-ganesha-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel>

Hi Daniel, Thanks for your prompt reply. I'm trying to implement the lock_op2 fct , we have a FS supporting lock owner basing on the host IP & pid of the program on the host (and also the file & ranges). That's why while converting from the Ganesha lock to FSAL lock, I need to find something to simulate the PID. Can you advice? Thank you On Fri, Jun 15, 2018 at 3:09 PM, Daniel Gryniewicz <dang(a)redhat.com <mailto:dang@redhat.com>> wrote: I don't believe there's any necessity for a client to send different client_id's for different processes, as long as it can tell locally which lock is which.  So a server cannot depend on these being different to do things. What exactly are you trying to achieve here?  What's the problem being solved? Daniel On 06/15/2018 05:24 AM, Tuan Viet Nguyen wrote: Hi Daniel, Thank you for your reply. I've also tried with the client_id but it also has the same value for 2 different processes. So if the client_id and the opaque always have the same value (for 2 different processes), how can we distinguish the client? I've tried with this field so_owner.so_nfs4_owner.so_clientid Thank you. Viet On Mon, Apr 30, 2018 at 2:38 PM, Daniel Gryniewicz <dang(a)redhat.com <mailto:dang@redhat.com> <mailto:dang@redhat.com <mailto:dang@redhat.com>>> wrote:     This list has been deprecated. Please subscribe to the new devel     list at lists.nfs-ganesha.org <http://lists.nfs-ganesha.org> <http://lists.nfs-ganesha.org>;.     Hi.     The client program ID in a lock owner is an opaque.  That is, it's     not defined in the spec, and the server can't use it for anything     other than a byte string.  The concatenation of the client-ID and     the opaque part of the lock owner is unique, but the opaque part of     the lock owner itself is not.     That value only has meaning to the client.     Daniel     On 04/30/2018 08:18 AM, Tuan Viet Nguyen wrote:         This list has been deprecated. Please subscribe to the new devel         list at lists.nfs-ganesha.org <http://lists.nfs-ganesha.org> <http://lists.nfs-ganesha.org>;.         Hello,         While trying to get more information related to the lock owner,         I'm trying to get the client program id and realize that it         always takes the same value (easy to do with a test program         forking another process, parent lock a file range then the child         locks another range). Is it something similar to the client         process id that is stored in the client record structure? or any         other suggestions?         Thank you ------------------------------------------------------------------------------         Check out the vibrant tech community on one of the world's most         engaging tech sites, Slashdot.org! http://sdm.link/slashdot         _______________________________________________         Nfs-ganesha-devel mailing list Nfs-ganesha-devel(a)lists.sourceforge.net <mailto:Nfs-ganesha-devel@lists.sourceforge.net>         <mailto:Nfs-ganesha-devel@lists.sourceforge.net <mailto:Nfs-ganesha-devel@lists.sourceforge.net>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel> <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel>> ------------------------------------------------------------------------------     Check out the vibrant tech community on one of the world's most     engaging tech sites, Slashdot.org! http://sdm.link/slashdot     _______________________________________________     Nfs-ganesha-devel mailing list Nfs-ganesha-devel(a)lists.sourceforge.net <mailto:Nfs-ganesha-devel@lists.sourceforge.net>     <mailto:Nfs-ganesha-devel@lists.sourceforge.net <mailto:Nfs-ganesha-devel@lists.sourceforge.net>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel> <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel>>

> 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