[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove unused codes of stallq

2017-10-13 Thread GerritHub 
>From Kinglong Mee :

Kinglong Mee has uploaded this change for review. ( 
https://review.gerrithub.io/382527


Change subject: Remove unused codes of stallq
..

Remove unused codes of stallq

Change-Id: If2d2b708b6231dcc5315fb657a20431fc48af880
Signed-off-by: Kinglong Mee 
---
M src/MainNFSD/nfs_rpc_dispatcher_thread.c
M src/include/gsh_rpc.h
M src/include/nfs_req_queue.h
3 files changed, 0 insertions(+), 14 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/27/382527/1
-- 
To view, visit https://review.gerrithub.io/382527
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: If2d2b708b6231dcc5315fb657a20431fc48af880
Gerrit-Change-Number: 382527
Gerrit-PatchSet: 1
Gerrit-Owner: Kinglong Mee 
--
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: RGW: set fso_compute_readdir_cookie

2017-10-13 Thread GerritHub 
>From Matt Benjamin :

Matt Benjamin has uploaded this change for review. ( 
https://review.gerrithub.io/382503


Change subject: RGW: set fso_compute_readdir_cookie
..

RGW: set fso_compute_readdir_cookie

The change that implement the method, didn't set the fs option.

Change-Id: I9d8e949d08eea8bb86e3a9a40514e52c927bcb26
Signed-off-by: Matt Benjamin 
---
M src/FSAL/FSAL_RGW/main.c
1 file changed, 12 insertions(+), 0 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/03/382503/1
-- 
To view, visit https://review.gerrithub.io/382503
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I9d8e949d08eea8bb86e3a9a40514e52c927bcb26
Gerrit-Change-Number: 382503
Gerrit-PatchSet: 1
Gerrit-Owner: Matt Benjamin 
--
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] pseudo mount issue with ganesha proxy server

2017-10-13 Thread Charles Short 

The ganesha server does not like the FSAL proxy config option -

13/10/2017 15:39:05 : epoch 59e0de19 : ganesha-cems : 
ganesha.nfsd-7820[main] config_errs_to_log :CONFIG :CRIT :Config File 
(/etc/ganesha/ganesha.conf:63): 1 validation errors in block FSAL
13/10/2017 15:39:05 : epoch 59e0de19 : ganesha-cems : 
ganesha.nfsd-7820[main] config_errs_to_log :CONFIG :CRIT :Config File 
(/etc/ganesha/ganesha.conf:63): Errors processing block (FSAL)
13/10/2017 15:39:05 : epoch 59e0de19 : ganesha-cems : 
ganesha.nfsd-7820[main] config_errs_to_log :CONFIG :CRIT :Config File 
(/etc/ganesha/ganesha.conf:38): 1 validation errors in block EXPORT


If I remove this from the config file   -
>>
FSAL {
    Name = PROXY;
    }
>>

The error goes away, but I still get the same issues I have outlined in 
the pastebin.


Charles
On 13/10/2017 16:37, Charles Short wrote:

Hi Patrice,

Thanks for this.
I have also noticed I may be missing some build options with cmake -

set(USE_FSAL_PROXY ON)

The above option was not by default in  everything.cmake, but I 
presume it is required along with set(PROXY_HANDLE_MAPPING ON) which 
is already there.


I will test the new config with the extra build option.

Regards

Charles


On 13/10/2017 13:34, LUCAS Patrice wrote:

Hello Charles,

You ganesha proxy-server configuration file seems to be a bit 
outdated (you can find an up to date example with this wiki link : 
https://github.com/nfs-ganesha/nfs-ganesha/wiki/Testing-FSAL_PROXY )


According to your configuration this one would be correct :

EXPORT
{
    # Export Id (mandatory, each EXPORT must have a unique 
Export_Id)

    Export_Id = 12345;

    # Exported path (mandatory)
    Path = /nfs;

    # Pseudo Path (required for NFS v4)
    Pseudo = /nfspath;

    # Required for access (default is None)
    # Could use CLIENT blocks instead
    Access_Type = RW;
    Squash = no_root_squash;

    # Exporting FSAL
    FSAL {
    Name = PROXY;
    }
}

LOG {
    COMPONENTS {
    #    ALL = FULL_DEBUG;
    }
}

NFSV4 {
#    GRACELESS = true;
}

PROXY {
    Remote_Server {
    Srv_Addr = [nfs-cems IP ADDR in XXX.XXX.XXX.XXX format];
    }
}


*MANDATORY : nfs-cems must be a NFSv4.1 server .

*With the current ganesha github version, clients of FSAL_PROXY must 
be NFSv4.1 client. Very recent patchs fix NFSv3 and NFSv4.0 client 
access to FSAL_PROXY, soon merged in up to date "next" version of 
ganesha.


Regards,
Patrice

On 10/13/17 13:21, Charles Short wrote:

More complete logs with all 'errors' -

https://pastebin.com/ZzRybVeE

On 13/10/2017 11:30, Charles Short wrote:

Hi,

I am testing a v simple ganesha proxy and get pseudo mount INODE 
errors on the ganesha server when I try and mount the NFS volume 
from client to proxy


##On server startup

13/10/2017 10:13:43 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[main] export_display :CONFIG :M_DBG :RESULT 
0xbc0e18 Export 12345 pseudo (/nfspath) with path (/nfs) and tag 
((null)) perms (options=033021e2 , RWrw, ,   
,   , , ,    , sys)


### On attempted client mount -


13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] nfs4_op_lookup :NFS4 :DEBUG 
:name=nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_lookup :INODE :F_DBG :Lookup 
nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_try_get_cached :INODE :F_DBG 
:Look in cache nfspath, trust content yes
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdcache_avl_qp_lookup_s :INODE 
:F_DBG :Lookup nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdcache_avl_qp_lookup_s :INODE 
:F_DBG :entry not found at j=1 (nfspath)
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_try_get_cached :INODE :F_DBG 
:mdcache_avl_qp_lookup_s nfspath failed trust negative no



The whole setup including build config files and logs is here

https://pastebin.com/DEnER83J

What am I doing wrong?

Thanks

Charles


-- 


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








--
Charles Short
Cloud Engineer
Virtualization and Cloud Team
European Bioinformatics Institute (EMBL-EBI)
Tel: +44 (0)1223 494205


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [Nfs-ganesha-devel] The life of tcp drc

2017-10-13 Thread Matt Benjamin 
Yes, nfs_rpc_free_user_data() is the secret :)

Matt

On Fri, Oct 13, 2017 at 4:11 AM, Kinglong Mee  wrote:
> Hi Malahal,
>
> Thanks for your reply.
>
> #1. I'd like to post a patch to delete it, because I have some cleanups for 
> drc.
> #2/#3. Sorry for my missing of nfs_rpc_free_user_data(). With it, everything 
> is okay.
>
> thanks,
> Kinglong Mee
>
> On 10/13/2017 15:52, Malahal Naineni wrote:
>> #1. Looks like a bug! Lines 629 and 630 should be deleted
>> #2. See nfs_rpc_free_user_data(). It sets xp_u2 to NULL and drc ref is 
>> decremented there.
>> #3. Life time of drc should start when it is allocated in 
>> nfs_dupreq_get_drc() using alloc_tcp_drc().
>>   It can live beyond xprt's xp_u2 setting to NULL. It will live until we 
>> decide to free in drc_free_expired() using free_tcp_drc().
>>
>> Regards, Malahal.
>> PS: The comment "drc cache maintains a ref count." seems to imply that it 
>> will have a refcount for keeping it in the hash table itself. I may have 
>> kept those two lines because of that but It doesn't make sense as refcnt 
>> will never go to zero this way.
>>
>> On Thu, Oct 12, 2017 at 3:48 PM, Kinglong Mee > > wrote:
>>
>> Describes in src/RPCAL/nfs_dupreq.c,
>>
>>  * The life of tcp drc: it gets allocated when we process the first
>>  * request on the connection. It is put into rbtree (tcp_drc_recycle_t).
>>  * drc cache maintains a ref count. Every request as well as the xprt
>>  * holds a ref count. Its ref count should go to zero when the
>>  * connection's xprt gets freed (all requests should be completed on the
>>  * xprt by this time). When the ref count goes to zero, it is also put
>>  * into a recycle queue (tcp_drc_recycle_q). When a reconnection
>>  * happens, we hope to find the same drc that was used before, and the
>>  * ref count goes up again. At the same time, the drc will be removed
>>  * from the recycle queue. Only drc's with ref count zero end up in the
>>  * recycle queue. If a reconnection doesn't happen in time, the drc gets
>>  * freed by drc_free_expired() after some period of inactivety.
>>
>> Some questions about the life time of tcp drc,
>> 1. The are two references of drc for xprt in nfs_dupreq_get_drc().
>>629 /* xprt ref */
>>630 drc->refcnt = 1;
>>...
>>638 (void)nfs_dupreq_ref_drc(drc);  /* xprt 
>> ref */
>>...
>>653 req->rq_xprt->xp_u2 = (void *)drc;
>>
>>I think it's a bug. The first one needs remove. Right?
>>
>> 2. The is no place to decrease the reference of drc for xprt.
>>The xprt argument in nfs_dupreq_put_drc() is unused.
>>Should it be used to decrease the ref?
>>I think it's the right place to decrease the ref in 
>> nfs_dupreq_put_drc().
>>
>> 3. My doubts is that, the life time of drc stored in req->rq_xprt->xp_u2 
>> ?
>>Start at #1, end at #2 (req->rq_xprt->xp_u2 = NULL) ?
>>If that, the bad case is always lookup drc from tcp_drc_recycle_t.
>>
>>Otherwise, don't put the reference at #2, when to put it?
>>the bad case is the drc ref always be 1 forever, am I right?
>>
>> thanks,
>> Kinglong Mee
>>
>> 
>> --
>> 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



-- 

Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-821-5101
fax.  734-769-8938
cel.  734-216-5309

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

[Nfs-ganesha-devel] FSAL_PROXY : client NFSv3 and NFSv4.0 bugs solved

2017-10-13 Thread LUCAS Patrice 

Hello everyone,


During last Fall Bakeathon, we brought bugs out when NFSv3 or NFSv4.0 
clients access a FSAL_PROXY  ganesha export. The two last patchs I 
submit fix these bugs.


*FSAL_PROXY : fix open from a NFSv4.0 client

https://review.gerrithub.io/#/c/381637/

*FSAL_PROXY: fix slotid index management

https://review.gerrithub.io/#/c/382427/


For example, CTHON tests (basic, general, special and lock) now run 
without any problem.




We can now consider that FSAL_PROXY can be successfully accessed by a 
client NFSv3, NFSv4.0 and NFSv4.1. I will add within few weeks NFSv3 
client and NFSv4.0 client (in addition of existing NFSv4.1 client) tests 
in the FSAL_PROXY CEA-HPC CI working on gerrithub.



Regards,

--
Patrice LUCAS
Ingenieur-Chercheur, CEA-DAM/DSSI/SISR/LA2S
tel : +33 (0)1 69 26 47 86
e-mail : patrice.lu...@cea.fr


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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove unused parameters "Dispatch_Max_Reqs" and "Dispatch_M...

2017-10-13 Thread GerritHub 
>From :

supriti.si...@suse.com has uploaded this change for review. ( 
https://review.gerrithub.io/382453


Change subject: Remove unused parameters "Dispatch_Max_Reqs" and 
"Dispatch_Max_Reqs_Xprt"
..

Remove unused parameters "Dispatch_Max_Reqs" and "Dispatch_Max_Reqs_Xprt"

Change-Id: I2fb02f89718df56e099353ecf8bfe25cc3f43a3e
Signed-off-by: Supriti Singh 
---
M src/config_samples/config.txt
M src/doc/man/ganesha-core-config.rst
M src/include/gsh_config.h
M src/support/nfs_read_conf.c
4 files changed, 0 insertions(+), 21 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/53/382453/1
-- 
To view, visit https://review.gerrithub.io/382453
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I2fb02f89718df56e099353ecf8bfe25cc3f43a3e
Gerrit-Change-Number: 382453
Gerrit-PatchSet: 1
Gerrit-Owner: supriti.si...@suse.com
--
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] pseudo mount issue with ganesha proxy server

2017-10-13 Thread LUCAS Patrice 

Hello Charles,

You ganesha proxy-server configuration file seems to be a bit outdated 
(you can find an up to date example with this wiki link : 
https://github.com/nfs-ganesha/nfs-ganesha/wiki/Testing-FSAL_PROXY )


According to your configuration this one would be correct :

EXPORT
{
# Export Id (mandatory, each EXPORT must have a unique Export_Id)
Export_Id = 12345;

# Exported path (mandatory)
Path = /nfs;

# Pseudo Path (required for NFS v4)
Pseudo = /nfspath;

# Required for access (default is None)
# Could use CLIENT blocks instead
Access_Type = RW;
Squash = no_root_squash;

# Exporting FSAL
FSAL {
Name = PROXY;
}
}

LOG {
COMPONENTS {
#ALL = FULL_DEBUG;
}
}

NFSV4 {
#GRACELESS = true;
}

PROXY {
Remote_Server {
Srv_Addr = [nfs-cems IP ADDR in XXX.XXX.XXX.XXX format];
}
}


*MANDATORY : nfs-cems must be a NFSv4.1 server .

*With the current ganesha github version, clients of FSAL_PROXY must be 
NFSv4.1 client. Very recent patchs fix NFSv3 and NFSv4.0 client access 
to FSAL_PROXY, soon merged in up to date "next" version of ganesha.


Regards,
Patrice

On 10/13/17 13:21, Charles Short wrote:

More complete logs with all 'errors' -

https://pastebin.com/ZzRybVeE

On 13/10/2017 11:30, Charles Short wrote:

Hi,

I am testing a v simple ganesha proxy and get pseudo mount INODE 
errors on the ganesha server when I try and mount the NFS volume from 
client to proxy


##On server startup

13/10/2017 10:13:43 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[main] export_display :CONFIG :M_DBG :RESULT 
0xbc0e18 Export 12345 pseudo (/nfspath) with path (/nfs) and tag 
((null)) perms (options=033021e2  , RWrw, ,   
,   , , ,    , sys)


### On attempted client mount -


13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] nfs4_op_lookup :NFS4 :DEBUG 
:name=nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_lookup :INODE :F_DBG :Lookup 
nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_try_get_cached :INODE :F_DBG 
:Look in cache nfspath, trust content yes
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdcache_avl_qp_lookup_s :INODE 
:F_DBG :Lookup nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdcache_avl_qp_lookup_s :INODE 
:F_DBG :entry not found at j=1 (nfspath)
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_try_get_cached :INODE :F_DBG 
:mdcache_avl_qp_lookup_s nfspath failed trust negative no



The whole setup including build config files and logs is here

https://pastebin.com/DEnER83J

What am I doing wrong?

Thanks

Charles


-- 


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




--
Patrice LUCAS
Ingenieur-Chercheur, CEA-DAM/DSSI/SISR/LA2S
tel : +33 (0)1 69 26 47 86
e-mail : patrice.lu...@cea.fr


--
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] pseudo mount issue with ganesha proxy server

2017-10-13 Thread Charles Short 

More complete logs with all 'errors' -

https://pastebin.com/ZzRybVeE

On 13/10/2017 11:30, Charles Short wrote:

Hi,

I am testing a v simple ganesha proxy and get pseudo mount INODE 
errors on the ganesha server when I try and mount the NFS volume from 
client to proxy


##On server startup

13/10/2017 10:13:43 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[main] export_display :CONFIG :M_DBG :RESULT 
0xbc0e18 Export 12345 pseudo (/nfspath) with path (/nfs) and tag 
((null)) perms (options=033021e2  , RWrw, ,   
,   , , ,    , sys)


### On attempted client mount -


13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] nfs4_op_lookup :NFS4 :DEBUG 
:name=nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_lookup :INODE :F_DBG :Lookup 
nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_try_get_cached :INODE :F_DBG 
:Look in cache nfspath, trust content yes
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdcache_avl_qp_lookup_s :INODE 
:F_DBG :Lookup nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdcache_avl_qp_lookup_s :INODE 
:F_DBG :entry not found at j=1 (nfspath)
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_try_get_cached :INODE :F_DBG 
:mdcache_avl_qp_lookup_s nfspath failed trust negative no



The whole setup including build config files and logs is here

https://pastebin.com/DEnER83J

What am I doing wrong?

Thanks

Charles


-- 


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


--
Charles Short
Cloud Engineer
Virtualization and Cloud Team
European Bioinformatics Institute (EMBL-EBI)
Tel: +44 (0)1223 494205


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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: FSAL_PROXY: fix slotid index management

2017-10-13 Thread GerritHub 
>From Patrice LUCAS :

Patrice LUCAS has uploaded this change for review. ( 
https://review.gerrithub.io/382427


Change subject: FSAL_PROXY: fix slotid index management
..

FSAL_PROXY: fix slotid index management

Change-Id: I1b421fc26721ca1b226a6b95d890e95910d053d2
Signed-off-by: Patrice LUCAS 
---
M src/FSAL/FSAL_PROXY/fsal_nfsv4_macros.h
M src/FSAL/FSAL_PROXY/handle.c
2 files changed, 3 insertions(+), 3 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/27/382427/1
-- 
To view, visit https://review.gerrithub.io/382427
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I1b421fc26721ca1b226a6b95d890e95910d053d2
Gerrit-Change-Number: 382427
Gerrit-PatchSet: 1
Gerrit-Owner: Patrice LUCAS 
--
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

[Nfs-ganesha-devel] pseudo mount issue with ganesha proxy server

2017-10-13 Thread Charles Short 

Hi,

I am testing a v simple ganesha proxy and get pseudo mount INODE errors 
on the ganesha server when I try and mount the NFS volume from client to 
proxy


##On server startup

13/10/2017 10:13:43 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[main] export_display :CONFIG :M_DBG :RESULT 0xbc0e18 
Export 12345 pseudo (/nfspath) with path (/nfs) and tag ((null)) perms 
(options=033021e2  , RWrw, ,   ,   
, , ,    , sys)


### On attempted client mount -


13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] nfs4_op_lookup :NFS4 :DEBUG :name=nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_lookup :INODE :F_DBG :Lookup nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_try_get_cached :INODE :F_DBG 
:Look in cache nfspath, trust content yes
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdcache_avl_qp_lookup_s :INODE :F_DBG 
:Lookup nfspath
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdcache_avl_qp_lookup_s :INODE :F_DBG 
:entry not found at j=1 (nfspath)
13/10/2017 10:14:39 : epoch 59e091d7 : ganesha-cems : 
ganesha.nfsd-19778[0x7facec5f3ee0] mdc_try_get_cached :INODE :F_DBG 
:mdcache_avl_qp_lookup_s nfspath failed trust negative no



The whole setup including build config files and logs is here

https://pastebin.com/DEnER83J

What am I doing wrong?

Thanks

Charles


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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: drc: remove some useless DRC flags

2017-10-13 Thread GerritHub 
>From Kinglong Mee :

Kinglong Mee has uploaded this change for review. ( 
https://review.gerrithub.io/382416


Change subject: drc: remove some useless DRC flags
..

drc: remove some useless DRC flags

Change-Id: Id6315ac9299d8b57f540bbdb272585f865db4a0d
Signed-off-by: Kinglong Mee 
---
M src/MainNFSD/nfs_rpc_dispatcher_thread.c
M src/RPCAL/nfs_dupreq.c
M src/include/nfs_dupreq.h
3 files changed, 10 insertions(+), 16 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/16/382416/1
-- 
To view, visit https://review.gerrithub.io/382416
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Id6315ac9299d8b57f540bbdb272585f865db4a0d
Gerrit-Change-Number: 382416
Gerrit-PatchSet: 1
Gerrit-Owner: Kinglong Mee 
--
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

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: drc: fix duplicate referance of drc for xprt

2017-10-13 Thread GerritHub 
>From Kinglong Mee :

Kinglong Mee has uploaded this change for review. ( 
https://review.gerrithub.io/382413


Change subject: drc: fix duplicate referance of drc for xprt
..

drc: fix duplicate referance of drc for xprt

Change-Id: I63d8c3dad1a5a4b0905dcbdb375b9f5b0860595a
Signed-off-by: Kinglong Mee 
---
M src/RPCAL/nfs_dupreq.c
1 file changed, 0 insertions(+), 2 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/13/382413/1
-- 
To view, visit https://review.gerrithub.io/382413
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I63d8c3dad1a5a4b0905dcbdb375b9f5b0860595a
Gerrit-Change-Number: 382413
Gerrit-PatchSet: 1
Gerrit-Owner: Kinglong Mee 
--
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] The life of tcp drc

2017-10-13 Thread Kinglong Mee 
Hi Malahal,

Thanks for your reply.

#1. I'd like to post a patch to delete it, because I have some cleanups for drc.
#2/#3. Sorry for my missing of nfs_rpc_free_user_data(). With it, everything is 
okay.

thanks,
Kinglong Mee

On 10/13/2017 15:52, Malahal Naineni wrote:
> #1. Looks like a bug! Lines 629 and 630 should be deleted
> #2. See nfs_rpc_free_user_data(). It sets xp_u2 to NULL and drc ref is 
> decremented there.
> #3. Life time of drc should start when it is allocated in 
> nfs_dupreq_get_drc() using alloc_tcp_drc().
>       It can live beyond xprt's xp_u2 setting to NULL. It will live until we 
> decide to free in drc_free_expired() using free_tcp_drc().
> 
> Regards, Malahal.
> PS: The comment "drc cache maintains a ref count." seems to imply that it 
> will have a refcount for keeping it in the hash table itself. I may have kept 
> those two lines because of that but It doesn't make sense as refcnt will 
> never go to zero this way.
> 
> On Thu, Oct 12, 2017 at 3:48 PM, Kinglong Mee  > wrote:
> 
> Describes in src/RPCAL/nfs_dupreq.c,
> 
>  * The life of tcp drc: it gets allocated when we process the first
>  * request on the connection. It is put into rbtree (tcp_drc_recycle_t).
>  * drc cache maintains a ref count. Every request as well as the xprt
>  * holds a ref count. Its ref count should go to zero when the
>  * connection's xprt gets freed (all requests should be completed on the
>  * xprt by this time). When the ref count goes to zero, it is also put
>  * into a recycle queue (tcp_drc_recycle_q). When a reconnection
>  * happens, we hope to find the same drc that was used before, and the
>  * ref count goes up again. At the same time, the drc will be removed
>  * from the recycle queue. Only drc's with ref count zero end up in the
>  * recycle queue. If a reconnection doesn't happen in time, the drc gets
>  * freed by drc_free_expired() after some period of inactivety.
> 
> Some questions about the life time of tcp drc,
> 1. The are two references of drc for xprt in nfs_dupreq_get_drc().
>    629                                 /* xprt ref */
>    630                                 drc->refcnt = 1;
>    ...
>    638                         (void)nfs_dupreq_ref_drc(drc);  /* xprt 
> ref */
>    ...
>    653                         req->rq_xprt->xp_u2 = (void *)drc;
> 
>    I think it's a bug. The first one needs remove. Right?
> 
> 2. The is no place to decrease the reference of drc for xprt.
>    The xprt argument in nfs_dupreq_put_drc() is unused.
>    Should it be used to decrease the ref?
>    I think it's the right place to decrease the ref in 
> nfs_dupreq_put_drc().
> 
> 3. My doubts is that, the life time of drc stored in req->rq_xprt->xp_u2 ?
>    Start at #1, end at #2 (req->rq_xprt->xp_u2 = NULL) ?
>    If that, the bad case is always lookup drc from tcp_drc_recycle_t.
> 
>    Otherwise, don't put the reference at #2, when to put it?
>    the bad case is the drc ref always be 1 forever, am I right?
> 
> thanks,
> Kinglong Mee
> 
> 
> --
> 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] The life of tcp drc

2017-10-13 Thread Malahal Naineni 
#1. Looks like a bug! Lines 629 and 630 should be deleted
#2. See nfs_rpc_free_user_data(). It sets xp_u2 to NULL and drc ref is
decremented there.
#3. Life time of drc should start when it is allocated
in nfs_dupreq_get_drc() using alloc_tcp_drc().
  It can live beyond xprt's xp_u2 setting to NULL. It will live until
we decide to free in drc_free_expired() using free_tcp_drc().

Regards, Malahal.
PS: The comment "drc cache maintains a ref count." seems to imply that it
will have a refcount for keeping it in the hash table itself. I may have
kept those two lines because of that but It doesn't make sense as refcnt
will never go to zero this way.

On Thu, Oct 12, 2017 at 3:48 PM, Kinglong Mee  wrote:

> Describes in src/RPCAL/nfs_dupreq.c,
>
>  * The life of tcp drc: it gets allocated when we process the first
>  * request on the connection. It is put into rbtree (tcp_drc_recycle_t).
>  * drc cache maintains a ref count. Every request as well as the xprt
>  * holds a ref count. Its ref count should go to zero when the
>  * connection's xprt gets freed (all requests should be completed on the
>  * xprt by this time). When the ref count goes to zero, it is also put
>  * into a recycle queue (tcp_drc_recycle_q). When a reconnection
>  * happens, we hope to find the same drc that was used before, and the
>  * ref count goes up again. At the same time, the drc will be removed
>  * from the recycle queue. Only drc's with ref count zero end up in the
>  * recycle queue. If a reconnection doesn't happen in time, the drc gets
>  * freed by drc_free_expired() after some period of inactivety.
>
> Some questions about the life time of tcp drc,
> 1. The are two references of drc for xprt in nfs_dupreq_get_drc().
>629 /* xprt ref */
>630 drc->refcnt = 1;
>...
>638 (void)nfs_dupreq_ref_drc(drc);  /* xprt ref
> */
>...
>653 req->rq_xprt->xp_u2 = (void *)drc;
>
>I think it's a bug. The first one needs remove. Right?
>
> 2. The is no place to decrease the reference of drc for xprt.
>The xprt argument in nfs_dupreq_put_drc() is unused.
>Should it be used to decrease the ref?
>I think it's the right place to decrease the ref in
> nfs_dupreq_put_drc().
>
> 3. My doubts is that, the life time of drc stored in req->rq_xprt->xp_u2 ?
>Start at #1, end at #2 (req->rq_xprt->xp_u2 = NULL) ?
>If that, the bad case is always lookup drc from tcp_drc_recycle_t.
>
>Otherwise, don't put the reference at #2, when to put it?
>the bad case is the drc ref always be 1 forever, am I right?
>
> thanks,
> Kinglong Mee
>
> 
> --
> 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