October 2018 - Devel - NFS Ganesha List Archives

Change in ffilz/nfs-ganesha[next]: Fix GTEST build
by GerritHub 16 Oct '18

16 Oct '18

From Daniel Gryniewicz <dang(a)redhat.com>: Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/429688 Change subject: Fix GTEST build ...................................................................... Fix GTEST build C++ doesn't like implicit cast from void* to char*. Add an explicit cast. Change-Id: If7eef507a45d870173a44b21665b4a28ce98cc9a Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com> --- M src/include/fsal.h 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/88/429688/1 -- To view, visit https://review.gerrithub.io/429688 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: If7eef507a45d870173a44b21665b4a28ce98cc9a Gerrit-Change-Number: 429688 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com>

1 0

Re: [Gluster-users] NFS-Ganesha question
by Jiffin Tony Thottan 16 Oct '18

16 Oct '18

CCing ganesha list as well On Monday 15 October 2018 07:44 PM, Renaud Fortier wrote: > > Hi, > > We are currently facing a strange behaviour with our cluster. Right > now I’m running bitrot scrub against the volume but I’m not sure it > will help finding the problem. Anyway, my question is about > nfs-ganesha and NFSv4. Since this strange behaviour begun, I read alot > and I found that idmapd is needed for NFSv4. If I run rpcinfo or ps > –ef |grep idmapd on our nodes, I don’t see it. > > Is rpc.idmapd supposed to be running when using nfs-ganesha 2.6.3 with > gluster 4.1.5 ? > IMO rpc.idmap as a service is not required for ganesha, but ganesha uses apis from "libnfsidmap" for id mapping for confirming the same CCing ganesha devel list as well. -- Jiffin > Thank you > > > > _______________________________________________ > Gluster-users mailing list > Gluster-users(a)gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users

3 2

Change in ffilz/nfs-ganesha[next]: SAL: Fix dead lock in revoke_owner_delegs()
by GerritHub 16 Oct '18

16 Oct '18

From Jiffin Tony Thottan <jthottan(a)redhat.com>: Jiffin Tony Thottan has uploaded this change for review. ( https://review.gerrithub.io/429624 Change subject: SAL: Fix dead lock in revoke_owner_delegs() ...................................................................... SAL: Fix dead lock in revoke_owner_delegs() state->lock held by revoke_owner_delegs() before calling mdcache_put_ref(), and code path again ends up in trying take lock on state->lock which will result in crash with following bt Change-Id: Iedb9bfb44027194a8adcfc535fd0cf70ba0f9808 Signed-off-by: Jiffin Tony Thottan <jthottan(a)redhat.com> --- M src/SAL/nfs4_state.c 1 file changed, 3 insertions(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/24/429624/1 -- To view, visit https://review.gerrithub.io/429624 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Iedb9bfb44027194a8adcfc535fd0cf70ba0f9808 Gerrit-Change-Number: 429624 Gerrit-PatchSet: 1 Gerrit-Owner: Jiffin Tony Thottan <jthottan(a)redhat.com>

1 0

Change in ffilz/nfs-ganesha[next]: FSAL_PROXY : module options
by GerritHub 16 Oct '18

16 Oct '18

From Patrice LUCAS <patrice.lucas(a)cea.fr>: Patrice LUCAS has uploaded this change for review. ( https://review.gerrithub.io/429595 Change subject: FSAL_PROXY : module options ...................................................................... FSAL_PROXY : module options The previous cabda8ff177a commit (gerrit patch 427714) deleted proxy option module block. But this blocks still exists and is separated from the export option. Change-Id: I08d08b08d29526fdfcb16eb3c971b86ea33ed4e8 Signed-off-by: Patrice LUCAS <patrice.lucas(a)cea.fr> --- M src/config_samples/config.txt M src/doc/man/ganesha-proxy-config.rst 2 files changed, 49 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/95/429595/1 -- To view, visit https://review.gerrithub.io/429595 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I08d08b08d29526fdfcb16eb3c971b86ea33ed4e8 Gerrit-Change-Number: 429595 Gerrit-PatchSet: 1 Gerrit-Owner: Patrice LUCAS <patrice.lucas(a)cea.fr>

1 0

Re: Ganesha 2.5.4 - usage of device major, minor
by Frank Filz 15 Oct '18

15 Oct '18

> - On the issue itself, I forgot to mention that we used SIGHUP to reload. As you > suggested, will work on a patch to cleanup device major/minor to reuse if > possible, although I understand delete is not completely supported via SIGHUP. > But I do see some action to remove even with SIGHUP. You have to use DBUS to unexport. I couldn’t come up with a way to do unexport with SIGHUP. Actually, I do have an idea, add a Unexport = true; option. If that's set and the export is present, unexport, otherwise ignore the export - then you can leave exports in your config but have them not be present.... If an export is removed with unexport, that should release it's filesystems, and then a filesystem re-scan has the potential of removing filesystems no longer present (but we have to be careful there, GPFS has some issues with filesystems going offline and then messing up exports). Frank > - On this list subscription - I did subscribe to the list as well as registered myself. > But I had trouble posting to the list, I had to login directly and post. I also not > received my own post yet, although I do and did get other posts. > > Regards. > Krishna Harathi > > > On 10/9/18, 4:19 PM, "Frank Filz" <ffilzlnx(a)mindspring.com> wrote: > > Ganesha's management of filesystems is probably not ideal. We can add new > ones, but I don't think we implemented removing unused ones. > > I would suggest looking at the filesystem management code to see if there's a > good way to remove them. > > You would have to unmount the filesystem, trigger Ganesha to clean up and > remove the filesystem, and then mount the new filesystem. > > The filesystem enumeration showed multiple entries using the same device > major and minor (all really related to the same filesystem, but something about > the way Linux handles volumes and such) which means Ganesha must pick a > filesystem to use for a given device major and minor. If the device major and > minor is reused and Ganesha hasn't cleaned out the old filesystem, it will detect > the duplicate and just re-use the original filesystem (which of course no longer is > mounted...). > > Frank > > > -----Original Message----- > > From: krishna.harathi(a)storagecraft.com > > [mailto:krishna.harathi@storagecraft.com] > > Sent: Tuesday, October 9, 2018 3:30 PM > > To: devel(a)lists.nfs-ganesha.org > > Subject: [NFS-Ganesha-Devel] Ganesha 2.5.4 - usage of device major, minor > > > > We are using Ganesha 2.5.4 VFS FSAL with FUSE based filesystem. > > > > During our testing of deleting existing exports and creating new ones, found > that > > if a device major and minor is reused, clients get ESTALE for accessing a > newly > > created export (nfs2 below). > > This seems to cause the following log entry, and explains the ESTALE > response. > > > > 04/10/2018 T15:16:59.769027-0700 : nfs-ganesha-26627[sigmgr] 1595 > > :claim_posix_filesystems :FSAL :INFO :Root fs for export /exports/nfs1 is > > /exports/nfs2 > > > > We use our own Exportid and unique FSID configured for each export in the > > configuration file. > > > > I would like to know more about the intent and purpose of the usage of > device > > major and minor of an export in this context. > > Any help in fixing this reuse issue is also appreciated. > > > > Thanks. > > > > > > Regards. > > Krishna Harathi > > _______________________________________________ > > Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an > email to > > devel-leave(a)lists.nfs-ganesha.org > >

4 6

double-free bug
by patrice.lucas＠cea.fr 15 Oct '18

15 Oct '18

Hello everyone, Frequent memory crashs have been occurring for few weeks in the nfs-ganesha CEA FSAL-PROXY continuous integration test. I finally make time for looking at these problems today by running the nfs-ganesha server under Address Sanitizer. I got the following stack wih a double-free error. Could anyone explain this error ? Someone who well understand the dup-req cache ? Or someone who already works with the code of the nfs4_op_test_stateid operation ? The nfs4_op_test_stateid was introduce this summer by gerrit patch 418826 <https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/418826> from fatih-acar <https://review.gerrithub.io/q/owner:fatih%2540gandi.net>, 07/22/2018. The dup-req cache stack seems to be involved in this error. Regards, Patrice ==7037==ERROR: AddressSanitizer: attempting double-free on 0x60200001ced0 in thread T7: #0 0x480c09 in __interceptor_free (/usr/bin/ganesha.nfsd+0x480c09) #1 0x897125 in gsh_free /opt/nfs-ganesha/src/include/abstract_mem.h:299 #2 0x896f88 in nfs4_op_test_stateid_Free /opt/nfs-ganesha/src/Protocols/NFS/nfs4_op_test_stateid.c:121 #3 0x703702 in nfs4_Compound_FreeOne /opt/nfs-ganesha/src/Protocols/NFS/nfs4_Compound.c:1081 #4 0x7042c4 in nfs4_Compound_Free /opt/nfs-ganesha/src/Protocols/NFS/nfs4_Compound.c:1119 #5 0x865c4a in nfs4_op_sequence /opt/nfs-ganesha/src/Protocols/NFS/nfs4_op_sequence.c:185 #6 0x6fd80f in nfs4_Compound /opt/nfs-ganesha/src/Protocols/NFS/nfs4_Compound.c:903 #7 0x67167c in nfs_rpc_process_request /opt/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1329 #8 0x663040 in nfs_rpc_valid_NFS /opt/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1539 #9 0x7ffff7bb94a1 in svc_vc_decode /opt/nfs-ganesha/src/libntirpc/src/svc_vc.c:824 #10 0x6542ce in nfs_rpc_decode_request /opt/nfs-ganesha/src/MainNFSD/nfs_rpc_dispatcher_thread.c:1341 #11 0x7ffff7bb934c in svc_vc_recv /opt/nfs-ganesha/src/libntirpc/src/svc_vc.c:797 #12 0x7ffff7bb47be in svc_rqst_xprt_task /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:767 #13 0x7ffff7bb51af in svc_rqst_epoll_events /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:939 #14 0x7ffff7bb4e94 in svc_rqst_epoll_loop /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:1012:8 #15 0x7ffff7bb38bf in svc_rqst_run_task /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:1048:14 #16 0x7ffff7bc077c in work_pool_thread /opt/nfs-ganesha/src/libntirpc/src/work_pool.c:181 #17 0x7ffff6367e24 in start_thread (/lib64/libpthread.so.0+0x7e24) #18 0x7ffff575c34c in __clone (/lib64/libc.so.6+0xf834c) 0x60200001ced0 is located 0 bytes inside of 4-byte region [0x60200001ced0,0x60200001ced4) freed by thread T10 here: #0 0x480c09 in __interceptor_free (/usr/bin/ganesha.nfsd+0x480c09) #1 0x897125 in gsh_free /opt/nfs-ganesha/src/include/abstract_mem.h:299 #2 0x896f88 in nfs4_op_test_stateid_Free /opt/nfs-ganesha/src/Protocols/NFS/nfs4_op_test_stateid.c:121 #3 0x703702 in nfs4_Compound_FreeOne /opt/nfs-ganesha/src/Protocols/NFS/nfs4_Compound.c:1081 #4 0x7042c4 in nfs4_Compound_Free /opt/nfs-ganesha/src/Protocols/NFS/nfs4_Compound.c:1119 #5 0xcec2a4 in nfs_dupreq_rele /opt/nfs-ganesha/src/RPCAL/nfs_dupreq.c:1315 #6 0x673196 in nfs_rpc_process_request /opt/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1442 #7 0x663040 in nfs_rpc_valid_NFS /opt/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1539 #8 0x7ffff7bb94a1 in svc_vc_decode /opt/nfs-ganesha/src/libntirpc/src/svc_vc.c:824 #9 0x6542ce in nfs_rpc_decode_request /opt/nfs-ganesha/src/MainNFSD/nfs_rpc_dispatcher_thread.c:1341 #10 0x7ffff7bb934c in svc_vc_recv /opt/nfs-ganesha/src/libntirpc/src/svc_vc.c:797 #11 0x7ffff7bb47be in svc_rqst_xprt_task /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:767 #12 0x7ffff7bb51af in svc_rqst_epoll_events /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:939 #13 0x7ffff7bb4e94 in svc_rqst_epoll_loop /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:1012:8 #14 0x7ffff7bb38bf in svc_rqst_run_task /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:1048:14 #15 0x7ffff7bc077c in work_pool_thread /opt/nfs-ganesha/src/libntirpc/src/work_pool.c:181 #16 0x7ffff6367e24 in start_thread (/lib64/libpthread.so.0+0x7e24) previously allocated by thread T10 here: #0 0x480e59 in calloc (/usr/bin/ganesha.nfsd+0x480e59) #1 0x89689a in gsh_calloc__ /opt/nfs-ganesha/src/include/abstract_mem.h:145 #2 0x895c4e in nfs4_op_test_stateid /opt/nfs-ganesha/src/Protocols/NFS/nfs4_op_test_stateid.c:88:3 #3 0x6fd80f in nfs4_Compound /opt/nfs-ganesha/src/Protocols/NFS/nfs4_Compound.c:903 #4 0x67167c in nfs_rpc_process_request /opt/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1329 #5 0x663040 in nfs_rpc_valid_NFS /opt/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1539 #6 0x7ffff7bb94a1 in svc_vc_decode /opt/nfs-ganesha/src/libntirpc/src/svc_vc.c:824 #7 0x6542ce in nfs_rpc_decode_request /opt/nfs-ganesha/src/MainNFSD/nfs_rpc_dispatcher_thread.c:1341 #8 0x7ffff7bb934c in svc_vc_recv /opt/nfs-ganesha/src/libntirpc/src/svc_vc.c:797 #9 0x7ffff7bb47be in svc_rqst_xprt_task /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:767 #10 0x7ffff7bb51af in svc_rqst_epoll_events /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:939 #11 0x7ffff7bb4e94 in svc_rqst_epoll_loop /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:1012:8 #12 0x7ffff7bb38bf in svc_rqst_run_task /opt/nfs-ganesha/src/libntirpc/src/svc_rqst.c:1048:14 #13 0x7ffff7bc077c in work_pool_thread /opt/nfs-ganesha/src/libntirpc/src/work_pool.c:181 #14 0x7ffff6367e24 in start_thread (/lib64/libpthread.so.0+0x7e24)

6 14

Change in ffilz/nfs-ganesha[next]: NFSv4: avoid delays when client recalls delegations
by GerritHub 15 Oct '18

15 Oct '18

From <fatih(a)gandi.net>: fatih(a)gandi.net has uploaded this change for review. ( https://review.gerrithub.io/429450 Change subject: NFSv4: avoid delays when client recalls delegations ...................................................................... NFSv4: avoid delays when client recalls delegations We should not check for conflicting delegations if the client already has one. If the client opens with CLAIM_DELEG, usually done when recalling a delegation according to the RFC, we should not delay it. Otherwise it adds a lot of overhead to some workloads (configure scripts, compilation) due to the use of sillyrename by the Linux NFS client (unlinking an open file). Change-Id: I6ac0ddc3966374c2f0552080b8b8ff7b0b2daa27 Signed-off-by: Fatih Acar <fatih.acar(a)gandi.net> --- M src/Protocols/NFS/nfs4_op_open.c 1 file changed, 3 insertions(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/50/429450/1 -- To view, visit https://review.gerrithub.io/429450 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: I6ac0ddc3966374c2f0552080b8b8ff7b0b2daa27 Gerrit-Change-Number: 429450 Gerrit-PatchSet: 1 Gerrit-Owner: Anonymous Coward <fatih(a)gandi.net>

1 0

Announce Push of V2.8-dev.1
by Frank Filz 12 Oct '18

12 Oct '18

Branch next Tag:V2.8-dev.1 Release Highlights * V4.2 security labels * V4.2 ALLOCATE and SEEK for FSAL_VFS * Sticky grace period * Allow exports to be referral points in FSAL_VFS * get_nodeid recovery backend op * FSAL_CEPH: kill off old session before the mount * Put NFSv4 Tag into compound_data_t so it can be used in log messages Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> Contents: b9a7850 Frank S. Filz V2.8-dev.1 40e64f8 Frank S. Filz FSAL_VFS: Implement fallocate method for ALLOCATE and DEALLOCATE ops 6bcc884 Frank S. Filz FSAL_VFS: Add seek2 method 4e62939 Frank S. Filz Put NFSv4 Tag into compound_data_t so it can be used in log messages faa9745 Sriram Patil Allow exports to be referral points in FSAL_VFS 8c13ae9 Jeff Layton FSAL_CEPH: kill off old session before the mount 6127871 Jeff Layton rados_cluster: implement get_nodeid recovery backend op 5492165 Jeff Layton SAL: add a new get_nodeid recovery backend operation 66c766a Jeff Layton SAL: convert current_grace to struct timespec cd8263f Jeff Layton NLM: convert nlm4_Test to sticky grace periods f3d11ec Jeff Layton NLM: convert nlm4_Share to sticky grace periods 0ae6687 Jeff Layton NLM: convert nlm4_Lock to sticky grace periods 02c0cae Jeff Layton NLM: convert nlm_Cancel to sticky grace periods bfc6921 Jeff Layton NFS: convert nfs4_op_removexattr to sticky grace periods 2778672 Jeff Layton NFS: convert nfs4_op_setxattr to sticky grace periods d6994e7 Jeff Layton NFS: convert nfs4_op_setattr to sticky grace periods 24a6315 Jeff Layton NFS: convert nfs4_op_rename to sticky grace periods eac2cab Jeff Layton NFS: convert nfs4_op_remove to sticky grace periods 688731d Jeff Layton NFS: don't check for grace period in nfs4_check_deleg_reclaim 7a80e65 Jeff Layton NFS: convert open code to use sticky grace periods 8c3b236 Jeff Layton NFSv4: convert nfs4_op_lockt to sticky grace period 050c726 Jeff Layton NFSv4: convert nfs4_op_lock to sticky grace period fcfce95 Jeff Layton NFS: convert nfs3_setattr to sticky grace period 99affe7 Jeff Layton 9p: take a sticky grace reference for lock ops 0155e67 Jeff Layton SAL: sticky grace periods d9bb095 Jeff Layton FSAL_CEPH: add support for security labels 1aca402 Jeff Layton FSAL_CEPH: add wrapper functions for xattrs f995e3c Jeff Layton NFS: add the security label to struct attrlist 68d4292 Jeff Layton RPC: add types and encoder/decoder for security labels

1 0

Change in ffilz/nfs-ganesha[next]: Merge branch 'ceph-cluster' into for-ffilz
by GerritHub 12 Oct '18

12 Oct '18

From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/429280 Change subject: Merge branch 'ceph-cluster' into for-ffilz ...................................................................... Merge branch 'ceph-cluster' into for-ffilz Change-Id: Ib884da50f313b0f5858687c558125d550ac93029 Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- 1 file changed, 0 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/80/429280/1 -- To view, visit https://review.gerrithub.io/429280 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: Ib884da50f313b0f5858687c558125d550ac93029 Gerrit-Change-Number: 429280 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>

1 0

Change in ffilz/nfs-ganesha[next]: Merge branch 'sticky-grace' into for-ffilz
by GerritHub 12 Oct '18

12 Oct '18

From Jeff Layton <jlayton(a)redhat.com>: Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/429279 Change subject: Merge branch 'sticky-grace' into for-ffilz ...................................................................... Merge branch 'sticky-grace' into for-ffilz Change-Id: If6f30735764374bdfd47665a55073a81430bcc1b Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- 1 file changed, 0 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/79/429279/1 -- To view, visit https://review.gerrithub.io/429279 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-MessageType: newchange Gerrit-Change-Id: If6f30735764374bdfd47665a55073a81430bcc1b Gerrit-Change-Number: 429279 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>

1 0