This list has been deprecated. Please subscribe to the new devel list at
lists.nfs-ganesha.org.
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 <d...@redhat.com
<mailto:d...@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@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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel