[Nfs-ganesha-devel] Announce Push of V2.7-dev.17

2018-06-15 Thread Frank Filz 
This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.Branch next

 

Tag:V2.7-dev.17

 

Release Highlights

 

* new gtests

 

* gtest improvements

 

* doc: cleanups and clarifications in rados_cluster design manpage

 

* rados_cluster: start grace period after creating new recovery DB

 

* src/FSAL/default_methods.c: return of handle_get_ref and handle_put_ref

 

* packaging: pkg install needs to mkdir /var/log/ganesha/

 

Signed-off-by: Frank S. Filz 

 

Contents:

 

6dcf23b Frank S. Filz V2.7-dev.17

0cc95c6 Kaleb S. KEITHLEY packaging: pkg install needs to mkdir
/var/log/ganesha/

311e46f grajoria src/FSAL/default_methods.c: return of handle_get_ref and
handle_put_ref

883acd7 grajoria gtest/fsal_api/ : update in open2, reopen2 and close2

c710de6 Jeff Layton rados_cluster: start grace period after creating new
recovery DB

fadbdba Jeff Layton doc: cleanups and clarifications in rados_cluster design
manpage

00e0cc3 Frank S. Filz gtest: nfs4_op_link

2d52e39 Frank S. Filz gtest: nfs4_op_rename also needs to set saved_export

c553d73 Frank S. Filz gtest: gtest_nfs4.hh add set_saved_export method

--
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

Re: [Nfs-ganesha-devel] cb_program or cb_callback_ident always the same

2018-06-15 Thread Daniel Gryniewicz 

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 > 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
mailto:d...@redhat.com>
>> wrote:

     This list has been deprecated. Please subscribe to the new
devel
     list at 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
 .



         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

         >
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

Re: [Nfs-ganesha-devel] cb_program or cb_callback_ident always the same

2018-06-15 Thread Tuan Viet Nguyen 
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  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 > > wrote:
>>
>> This list has been deprecated. Please subscribe to the new devel
>> list at 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 .
>>
>>
>>
>> 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
>> 
>> 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
>> 
>>
>>
>>
>
--
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

Re: [Nfs-ganesha-devel] cb_program or cb_callback_ident always the same

2018-06-15 Thread Daniel Gryniewicz 

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 > wrote:


This list has been deprecated. Please subscribe to the new devel
list at 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 .



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

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






--
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

Re: [Nfs-ganesha-devel] cb_program or cb_callback_ident always the same

2018-06-15 Thread Tuan Viet Nguyen 
This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.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  wrote:

> This list has been deprecated. Please subscribe to the new devel list at
> 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.
>>
>>
>>
>> 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
>> 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
>
--
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