May 2019 - Devel - NFS Ganesha List Archives

Change in ...nfs-ganesha[next]: Adding Trace to fsal_gluster
by Arjun Sharma (GerritHub) 02 May '19

02 May '19

Arjun Sharma has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/452880 Change subject: Adding Trace to fsal_gluster ...................................................................... Adding Trace to fsal_gluster WIP Signed-off-by: Arjun Sharma <arjsharm(a)redhat.com> Change-Id: I641ffd40f4824c4d3068c2342a7efeef0564c90b --- M src/FSAL/FSAL_GLUSTER/CMakeLists.txt M src/FSAL/FSAL_GLUSTER/export.c M src/FSAL/FSAL_GLUSTER/gluster_internal.c M src/FSAL/FSAL_GLUSTER/handle.c M src/MainNFSD/nfs_main.c A src/include/gsh_lttng/fsal_gluster.h M src/tracing/CMakeLists.txt A src/tracing/fsal_gluster.c 8 files changed, 820 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/80/452880/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/452880 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I641ffd40f4824c4d3068c2342a7efeef0564c90b Gerrit-Change-Number: 452880 Gerrit-PatchSet: 1 Gerrit-Owner: Arjun Sharma <arjsharm(a)redhat.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: Pull up ntirpc through #174
by Daniel Gryniewicz (GerritHub) 02 May '19

02 May '19

Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/452874 Change subject: Pull up ntirpc through #174 ...................................................................... Pull up ntirpc through #174 Change-Id: Ie8d9268d092bc7f854fa245e7849558377f8f57a Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com> --- M src/libntirpc 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/74/452874/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/452874 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Ie8d9268d092bc7f854fa245e7849558377f8f57a Gerrit-Change-Number: 452874 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: NFS4 - Allow locking past the FSAL's maxfilesize
by Daniel Gryniewicz (GerritHub) 02 May '19

02 May '19

Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/452873 Change subject: NFS4 - Allow locking past the FSAL's maxfilesize ...................................................................... NFS4 - Allow locking past the FSAL's maxfilesize rfc5661 only allows lock failers when the offset + length overflows a 64-bit integer. However, many FSALs have a max file size of 63-bits. We were returning BAD_RANGE in this case. It seems better to allow this, so fix it up so that an attempt to lock past maxfilesize will be transformed into "lock the rest of the file". Change-Id: I634ea27cc2dfe22e91ace0ddb9027d2bc36906c6 Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com> --- M src/Protocols/NFS/nfs4_op_lock.c M src/Protocols/NFS/nfs4_op_lockt.c M src/Protocols/NFS/nfs4_op_locku.c 3 files changed, 12 insertions(+), 24 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/73/452873/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/452873 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I634ea27cc2dfe22e91ace0ddb9027d2bc36906c6 Gerrit-Change-Number: 452873 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com> Gerrit-MessageType: newchange

1 0

For NLM UNLOCK - connection to rpc.statd not getting closed
by Madhu Thorat 02 May '19

02 May '19

Hi, Not sure if my previous mail was sent, hence re-sending the mail. I used the latest ganesha code and ran the following test from a NFSv3 client in a script: ct=0 while [ $ct -lt 4096 ]; do flock -x mylock echo 1 >> myfile let ct=$ct+1 done After running for 1000+ times the client got error "No locks available" ganesha.log had the following trace: ganesha.nfsd-9328[svc_103] nsm_connect :NLM :CRIT :connect to statd failed: RPC: Unknown protocol /var/log/messages showed "Too many open files" message. It looks like for NLM LOCK requests connection to rpc.statd were created but not closed for NLM UNLOCK request. After analyzing the code, it seems this happens because for NLM LOCK request the 'xprt->xp_refcnt' is ref'ed twice. But while handling NLM UNLOCK request the 'xprt->xp_refcnt' is un-ref'ed only once, and thus svc_vc_destroy_it() doesn't get called and connection to rpc.statd is not closed. More details about the code analysis is below. Can you please check about this issue ? Thank you. I am not sure why are we incrementing 'xprt->xp_refcnt' twice in svc_xprt_lookup() ? For NLM LOCK request the code path is: -------------------------------------------------------------- nlm4_Lock() -> ...... -> nsm_connect() -> ....... -> makefd_xprt() -> svc_xprt_lookup() 137 SVCXPRT * 138 svc_xprt_lookup(int fd, svc_xprt_setup_t setup) 139 { ...... ...... 173 (*setup)(&xprt); /* zalloc, xp_refcnt = 1 */ --> leads to call to svc_vc_xprt_setup() 174 xprt->xp_fd = fd; 175 xprt->xp_flags = SVC_XPRT_FLAG_INITIAL; 176 177 /* Get ref for caller */ 178 SVC_REF(xprt, SVC_REF_FLAG_NONE); Here, at line 173 function svc_vc_xprt_setup() is called which sets 'xprt->xp_refcnt = 1' Then at line 178, SVC_REF increments 'xprt->xp_refcnt' by 1. Thus, when handling NLM LOCK request 'xprt->xp_refcnt = 2' is set. For NLM UNLOCK request the code path is: ------------------------------------------------------------------- nlm4_Unlock() -> ...... -> nsm_disconnect -> ..... -> clnt_vc_destroy() -> svc_release_it() 410 static inline void svc_release_it(SVCXPRT *xprt, u_int flags, 411 const char *tag, const int line) 412 { 413 int32_t refs = atomic_dec_int32_t(&xprt->xp_refcnt); ...... ...... 425 if (likely(refs > 0)) { 426 /* normal case */ 427 return; 428 } 429 430 /* enforce once-only semantic, trace others */ 431 xp_flags = atomic_postset_uint16_t_bits(&xprt->xp_flags, 432 SVC_XPRT_FLAG_RELEASING); ...... 439 /* Releasing last reference */ 440 (*(xprt)->xp_ops->xp_destroy)(xprt, flags, tag, line); Here, at line 413 'xprt->xp_refcnt' gets decremented and becomes 'xprt->xp_refcnt = 1'. But as 'xprt->xp_refcnt != 0' the function returns from line 427. And thus it doesn't proceed with closure of connection. Thanks, Madhu Thorat IBM Pune.

3 5

open_fd_count incremented unconditionally
by srikrishanmalik＠gmail.com 01 May '19

01 May '19

Hello, For unchecked creates ganesha may increment open_fd_count even when no new fd is created by ganesha. This can happen for v3 when an fd for a file is already open and the client sends a create(unchecked) for the same file, the fsal closes the old fd and reopens the file, but fsal_helper.c:open_by_name increments open_fd_count without checking(no way to do that) whether a new fd is really created. We will hit this when two clients are trying to create the same file simultaneously, i.e lookup from both clients will fail and both will issue a create, the file will be opened by the first create, the other create will end up just incrementing open_fd_count. There is a patch(https://gerrithub.io/c/ffilz/nfs-ganesha/+/391267) which may address this, any plans to take this? Thanks Sri

2 1