Change in ffilz/nfs-ganesha[next]: Fix GTEST build
by GerritHub
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>
5 years, 6 months
Re: [Gluster-users] NFS-Ganesha question
by Jiffin Tony Thottan
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
5 years, 6 months
Change in ffilz/nfs-ganesha[next]: SAL: Fix dead lock in revoke_owner_delegs()
by GerritHub
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>
5 years, 6 months
Change in ffilz/nfs-ganesha[next]: FSAL_PROXY : module options
by GerritHub
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>
5 years, 6 months
Re: Ganesha 2.5.4 - usage of device major, minor
by Frank Filz
> - 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
>
>
5 years, 6 months
double-free bug
by patrice.lucas＠cea.fr
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)
5 years, 6 months
Change in ffilz/nfs-ganesha[next]: NFSv4: avoid delays when client recalls delegations
by GerritHub
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>
5 years, 6 months
Announce Push of V2.8-dev.1
by Frank Filz
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
5 years, 6 months
Change in ffilz/nfs-ganesha[next]: Merge branch 'ceph-cluster' into for-ffilz
by GerritHub
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>
5 years, 6 months
Change in ffilz/nfs-ganesha[next]: Merge branch 'sticky-grace' into for-ffilz
by GerritHub
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>
5 years, 6 months