This list has been deprecated. Please subscribe to the new devel list at
lists.nfs-ganesha.org.
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 <d...@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 <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
