This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.
I think you should just use the client_id. If the client doesn't distinguish between them, you can't, and probably shouldn't.

Daniel

On 06/15/2018 09:36 AM, Tuan Viet Nguyen wrote:
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 <mailto: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>
        <mailto: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> <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@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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Reply via email to