October 2021 - Devel - NFS Ganesha List Archives

Change in ...nfs-ganesha[next]: MDCACHE - Ensure ATTR4_FS_LOCATIONS and ATTR4_SEC_LABEL bits aren't lost
by Daniel Gryniewicz (GerritHub) 20 Oct '21

20 Oct '21

Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525891 ) Change subject: MDCACHE - Ensure ATTR4_FS_LOCATIONS and ATTR4_SEC_LABEL bits aren't lost ...................................................................... MDCACHE - Ensure ATTR4_FS_LOCATIONS and ATTR4_SEC_LABEL bits aren't lost The refresh/copy/ref-handoff code depends on the ATTR4_* bits in request_mask always matching the associated pointers. However, mdcache_refresh_attrs() overwrites request_mask with the given one, losing this relationship. Fix it up, to make sure the bits are always set when the pointers are non-NULL. This was already done for ACL, but not for FS_LOCATIONS or SEC_LABEL Change-Id: I5784a797545f0ab4bf8562594431134484fbe757 Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com> --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c 1 file changed, 11 insertions(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/91/525891/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525891 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: I5784a797545f0ab4bf8562594431134484fbe757 Gerrit-Change-Number: 525891 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: Remove ambiguous use of "export" in header file
by Matthew DeVore (GerritHub) 19 Oct '21

19 Oct '21

Matthew DeVore has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525846 ) Change subject: Remove ambiguous use of "export" in header file ...................................................................... Remove ambiguous use of "export" in header file fsal_commonlib.h cannot be easily included from a C++ source file because it uses "export" as a parameter name, which is a C++ keyword. This is the only instance of "export" causing problems for me at the moment. I didn't do a global cleanup as this would unnecessarily change headers that are not part of Ganesha's public API. Signed-off-by: Matthew DeVore <matvore(a)google.com> Change-Id: I72b95e2124a90c82438a30457fc092e3cf7a5c32 --- M src/include/FSAL/fsal_commonlib.h 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/46/525846/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525846 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: I72b95e2124a90c82438a30457fc092e3cf7a5c32 Gerrit-Change-Number: 525846 Gerrit-PatchSet: 1 Gerrit-Owner: Matthew DeVore <me(a)matvore.com> Gerrit-MessageType: newchange

1 0

compile error for nfs-ganesha-2.8.1.2-0.1.el7.src.rpm on CentOS7
by boisdesdames＠gmail.com 19 Oct '21

19 Oct '21

Hi, I try to recompile package nfs-ganesha-2.8.1.2-0.1.el7.src.rpm downloaded from . My server has Nautilus 14.2.22 libraries installed. I get the following errors: [root@namespace tmp]# rpmbuild --rebuild /tmp/nfs-ganesha-2.8.1.2-0.1.el7.src.rpm .... Scanning dependencies of target fsalrgw [ 85%] Building C object FSAL/FSAL_RGW/CMakeFiles/fsalrgw.dir/up.c.o [ 85%] Building C object FSAL/FSAL_RGW/CMakeFiles/fsalrgw.dir/main.c.o [ 85%] Building C object FSAL/FSAL_RGW/CMakeFiles/fsalrgw.dir/export.c.o /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/export.c: In function 'lookup_path': /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/export.c:160:6: error: too few arguments to function 'rgw_lookup' &rgw_dh, RGW_LOOKUP_FLAG_NONE); ^ In file included from /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/internal.h:45:0, from /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/export.c:38: /usr/include/rados/rgw_file.h:103:5: note: declared here int rgw_lookup(struct rgw_fs *rgw_fs, ^ /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/export.c:166:6: warning: passing argument 5 of 'rgw_lookup' makes pointer from integer without a cast [enabled by default] &rgw_fh, RGW_LOOKUP_FLAG_RCB); ^ In file included from /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/internal.h:45:0, from /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/export.c:38: /usr/include/rados/rgw_file.h:103:5: note: expected 'struct stat *' but argument is of type 'int' int rgw_lookup(struct rgw_fs *rgw_fs, ^ /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/export.c:166:6: error: too few arguments to function 'rgw_lookup' &rgw_fh, RGW_LOOKUP_FLAG_RCB); ^ In file included from /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/internal.h:45:0, from /root/rpmbuild/BUILD/nfs-ganesha-2.8.1.2/FSAL/FSAL_RGW/export.c:38: /usr/include/rados/rgw_file.h:103:5: note: declared here int rgw_lookup(struct rgw_fs *rgw_fs, .... Any idea ? Best regards, Patrick

2 1

Change in ...nfs-ganesha[next]: FSAL: Make sure the exclusive create verifier fits
by Frank Filz (GerritHub) 15 Oct '21

15 Oct '21

Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525711 ) Change subject: FSAL: Make sure the exclusive create verifier fits ...................................................................... FSAL: Make sure the exclusive create verifier fits For FSAL_VFS, some filesystems may not allow a full 32 bit atime or mtime. If this happens and the value is truncated or clamped (set to INT32_MAX), then try again masking off each 32 bit component to just be 31 bits. We set a flag in the fsal_filesystem in the future, all verifiers will be truncated in this way which also assures that the validation of the verifier works correctly. Change-Id: I0283fffcde0ef40313eaa657560802a5f77b3549 Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> --- M src/FSAL/FSAL_CEPH/handle.c M src/FSAL/FSAL_GLUSTER/handle.c M src/FSAL/FSAL_GPFS/file.c M src/FSAL/FSAL_KVSFS/kvsfs_file.c M src/FSAL/FSAL_LIZARDFS/handle.c M src/FSAL/FSAL_MEM/mem_handle.c M src/FSAL/FSAL_RGW/handle.c M src/FSAL/FSAL_VFS/file.c M src/FSAL/commonlib.c M src/FSAL/default_methods.c M src/include/FSAL/fsal_commonlib.h M src/include/FSAL/fsal_localfs.h 12 files changed, 113 insertions(+), 30 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/11/525711/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525711 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: I0283fffcde0ef40313eaa657560802a5f77b3549 Gerrit-Change-Number: 525711 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: Make OPEN create EXCLUSIVE4_1 work correctly
by Frank Filz (GerritHub) 15 Oct '21

15 Oct '21

Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525710 ) Change subject: Make OPEN create EXCLUSIVE4_1 work correctly ...................................................................... Make OPEN create EXCLUSIVE4_1 work correctly Change-Id: I320f207be8caef5ba97cf8a1ab8c08aea1f534f4 Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> --- M src/Protocols/NFS/nfs4_op_open.c M src/Protocols/NFS/nfs_proto_tools.c 2 files changed, 24 insertions(+), 16 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/10/525710/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525710 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: I320f207be8caef5ba97cf8a1ab8c08aea1f534f4 Gerrit-Change-Number: 525710 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com> Gerrit-MessageType: newchange

1 0

ganesha is not honoring the nfsv4 acl
by Andrea Cucciarre 13 Oct '21

13 Oct '21

I'm trying to figure out why ganesha is not honoring the nfsv4 acl On the backend filesystem the NFSv4 seems to be properly configured: # nfs4_getfacl /hyperfile/volumes/1/6_1/dir_1 A::andrea:rwaxtTnNcCy However, on the NFS client user "andrea" can't access the directory $ mount -v | grep nfs 10.130.42.92:/vol1 on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.50.50.37,local_lock=none,addr=10.130.42.92) $ cd /mnt/dir_1 -bash: cd: /mnt/dir_1: Permission denied The UID for andrea is the same on NFS client and NFS ganesha server. I have enabled debug logs in Ganesha, but it doesn't say much to me (I have grepped for ACL) 3/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_56] nfs_access_op :NFS3 :DEBUG :access_mask = mode(rwx) ACL(list_dir,add_file,execute,add_subdirectory,delete_child) 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_56] fsal_check_access_no_acl :NFS4 ACL :F_DBG :file Mode=0777, file uid=0, file gid= 0, user uid=10001, user gid= 10002, access_type=0X7000000 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_56] fsal_check_access_no_acl :NFS4 ACL :F_DBG :Mask=0X7000000, Access Type=0X7000000 Allowed=0X7000000 Denied=0X0 ALLOWED 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_56] file_To_Fattr :NFS4 ACL :DEBUG :No permission check for ACL for obj 0x563029ad02f8 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_53] fsal_check_access_no_acl :NFS4 ACL :F_DBG :file Mode=0777, file uid=0, file gid= 0, user uid=10001, user gid= 10002, access_type=0X1000000 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_53] fsal_check_access_no_acl :NFS4 ACL :F_DBG :Mask=0X7000000, Access Type=0X1000000 Allowed=0X1000000 Denied=0X0 ALLOWED 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_53] file_To_Fattr :NFS4 ACL :DEBUG :No permission check for ACL for obj 0x7f7ca4003748 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_57] nfs_access_op :NFS3 :DEBUG :access_mask = mode(rwx) ACL(list_dir,add_file,execute,add_subdirectory,delete_child) 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_57] fsal_check_access_no_acl :NFS4 ACL :F_DBG :file Mode=0, file uid=0, file gid= 0, user uid=10001, user gid= 10002, access_type=0X7000000 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_57] fsal_check_access_no_acl :NFS4 ACL :F_DBG :Mask=0X0, Access Type=0X7000000 Allowed=0X0 Denied=0X7000000 DENIED 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf-gmlqp : nfs-ganesha-124687[svc_57] file_To_Fattr :NFS4 ACL :DEBUG :No permission check for ACL for obj 0x7f7ca4003748

5 6

Re: [EXTERNAL] ganesha is not honoring the nfsv4 acl
by Frank Filz 13 Oct '21

13 Oct '21

Maybe someone actually familiar with FSAL_PROXY_V4 can chime in. I wrote the below after doing a "grep -in acl" of the code. FSAL_PROXY_V4 showed up, but only a few times compared to the other FSALs that have ACL support so it might be incomplete. Frank > -----Original Message----- > From: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] > [mailto:jeffrey.c.becker@nasa.gov] > Sent: Wednesday, October 13, 2021 10:08 AM > To: Frank Filz <ffilzlnx(a)mindspring.com>; 'Andrea Cucciarre' > <acucciarre(a)cloudian.com> > Subject: Re: [NFS-Ganesha-Devel] Re: [EXTERNAL] ganesha is not honoring the > nfsv4 acl > > I am using FSAL_PROXY_V4 > > On 10/13/21, 10:06 AM, "Frank Filz" <ffilzlnx(a)mindspring.com> wrote: > > Ganesha currently has limited ACL support. > > FSAL_GPFS supports NFSv4 ACLs on the backend > > FSAL_CEPH and FSAL_GLUSTER support conversion between NFSv4 ACLs and > POSIX ACLs to be stored as POSIX ACLs on the backend > > FSAL_LIZARDFS has ACL support but I know almost nothing about Lizardfs to > evaluate how it's stored. > > FSAL_PROXY_V4 looks like it has ACL support, I don't know if it actually works. > > Beyond that, Ganesha doesn't support ACLs. It does not support the sideband > protocol to do POSIX ACLs for NFSv3 mounts. > > There was a discussion on IRC about FSAL_VFS supporting ACLs for filesystems > that support using NFSv4 ACLs via nfs4_get/setfacl. In theory, we could bend > things to support NFSv4 re-export and then hook into the ACLs (and that could > then work for any other filesystem that also decided to implement ACLs using > the same interface) but there are no immediate plans to do so and re-export > would be tricky and is honestly better done by FSAL_PROXY_V4 limiting our > incentive to support FSAL_VFS NFS re-export with ACLs. > > Frank > > > -----Original Message----- > > From: Becker, Jeffrey C. (ARC-TN)[InuTeq, LLC] via Devel > > [mailto:devel@lists.nfs-ganesha.org] > > Sent: Wednesday, October 13, 2021 8:51 AM > > To: Andrea Cucciarre <acucciarre(a)cloudian.com>; devel(a)lists.nfs- > ganesha.org > > Subject: [NFS-Ganesha-Devel] Re: [EXTERNAL] ganesha is not honoring the > nfsv4 > > acl > > > > I am seeing a similar situation with Ganesha and an NFSv4 mount of a > directory > > on which I've run setfacl, and the user in the setfacl gets permission denied. > > > > -Jeff > > > > On 10/13/21, 7:06 AM, "Andrea Cucciarre via Devel" <devel(a)lists.nfs- > > ganesha.org> wrote: > > > > I'm trying to figure out why ganesha is not honoring the nfsv4 acl > > > > On the backend filesystem the NFSv4 seems to be properly configured: > > > > # nfs4_getfacl /hyperfile/volumes/1/6_1/dir_1 > > A::andrea:rwaxtTnNcCy > > > > However, on the NFS client user "andrea" can't access the directory > > > > $ mount -v | grep nfs > > 10.130.42.92:/vol1 on /mnt type nfs4 > > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tc > > > p,timeo=600,retrans=2,sec=sys,clientaddr=10.50.50.37,local_lock=none,addr=1 > > 0.130.42.92) > > > > $ cd /mnt/dir_1 > > -bash: cd: /mnt/dir_1: Permission denied > > > > The UID for andrea is the same on NFS client and NFS ganesha server. > > > > I have enabled debug logs in Ganesha, but it doesn't say much to me (I > have > > grepped for ACL) > > > > 3/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_56] nfs_access_op :NFS3 :DEBUG :access_mask = > > mode(rwx) ACL(list_dir,add_file,execute,add_subdirectory,delete_child) > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_56] fsal_check_access_no_acl :NFS4 ACL :F_DBG > :file > > Mode=0777, file uid=0, file gid= 0, user uid=10001, user gid= 10002, > > access_type=0X7000000 > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_56] fsal_check_access_no_acl :NFS4 ACL :F_DBG > > :Mask=0X7000000, Access Type=0X7000000 Allowed=0X7000000 > Denied=0X0 > > ALLOWED > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_56] file_To_Fattr :NFS4 ACL :DEBUG :No > permission > > check for ACL for obj 0x563029ad02f8 > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_53] fsal_check_access_no_acl :NFS4 ACL :F_DBG > :file > > Mode=0777, file uid=0, file gid= 0, user uid=10001, user gid= 10002, > > access_type=0X1000000 > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_53] fsal_check_access_no_acl :NFS4 ACL :F_DBG > > :Mask=0X7000000, Access Type=0X1000000 Allowed=0X1000000 > Denied=0X0 > > ALLOWED > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_53] file_To_Fattr :NFS4 ACL :DEBUG :No > permission > > check for ACL for obj 0x7f7ca4003748 > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_57] nfs_access_op :NFS3 :DEBUG :access_mask = > > mode(rwx) ACL(list_dir,add_file,execute,add_subdirectory,delete_child) > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_57] fsal_check_access_no_acl :NFS4 ACL :F_DBG > :file > > Mode=0, file uid=0, file gid= 0, user uid=10001, user gid= 10002, > > access_type=0X7000000 > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_57] fsal_check_access_no_acl :NFS4 ACL :F_DBG > > :Mask=0X0, Access Type=0X7000000 Allowed=0X0 Denied=0X7000000 > DENIED > > > > 13/10/2021 13:53:15 : epoch 6166dd9b : hf-frontend-1-1-699f6cb8cf- > gmlqp : > > nfs-ganesha-124687[svc_57] file_To_Fattr :NFS4 ACL :DEBUG :No > permission > > check for ACL for obj 0x7f7ca4003748 > > _______________________________________________ > > Devel mailing list -- devel(a)lists.nfs-ganesha.org > > To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org > > > > _______________________________________________ > > Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an > email to > > devel-leave(a)lists.nfs-ganesha.org >

1 0

Change in ...nfs-ganesha[next]: Account for terminating null character for readlink() in FSAL_PROXY_V3.
by Bjorn Leffler (GerritHub) 12 Oct '21

12 Oct '21

Bjorn Leffler has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525514 ) Change subject: Account for terminating null character for readlink() in FSAL_PROXY_V3. ...................................................................... Account for terminating null character for readlink() in FSAL_PROXY_V3. Signed-off-by: Bjorn Leffler <leffler(a)google.com> Change-Id: I96d65645af68dd415eeafafbfec93810acd9f841 --- M src/FSAL/FSAL_PROXY_V3/main.c 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/14/525514/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525514 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: I96d65645af68dd415eeafafbfec93810acd9f841 Gerrit-Change-Number: 525514 Gerrit-PatchSet: 1 Gerrit-Owner: Bjorn Leffler <leffler(a)google.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: Fix number formatting for 64 bit number types.
by Bjorn Leffler (GerritHub) 12 Oct '21

12 Oct '21

Bjorn Leffler has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525512 ) Change subject: Fix number formatting for 64 bit number types. ...................................................................... Fix number formatting for 64 bit number types. I don't use this, nor have I tested it. This was flagged as a compiler warning. Signed-off-by: Bjorn Leffler <leffler(a)google.com> Change-Id: I747ae7121f2e91b1369e9f2c63e92d1040f561c2 --- M src/log/test_display.c 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/12/525512/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/525512 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: I747ae7121f2e91b1369e9f2c63e92d1040f561c2 Gerrit-Change-Number: 525512 Gerrit-PatchSet: 1 Gerrit-Owner: Bjorn Leffler <leffler(a)google.com> Gerrit-MessageType: newchange

1 0

Re: ganesha_mgr add_export command returning premature success when underlying storage is slow
by Frank Filz 12 Oct '21

12 Oct '21

The ganesha_mgr python script must be timing out since the DBUS service thread is blocked in your FSAL. I'm not sure what kind of library call you would want, and any interface like that would be added to Ganesha V5 (we just decided this morning to start the release candidate cycle for V4 so no more features will be accepted into V4). V4 will have a robust dynamic export config with updates triggered by SIGHUP though you wouldn't know when the update process is complete. The existing interface that DBUS calls or even the interface SIGHUP calls could be exported so you could hook up your own trigger either by incorporating Ganesha as library into your own front end, or driving the interface from code in your FSAL .so, either could then expose some kind of control interface that suits your needs better. If it's just a matter of making sure the existing interfaces are exported of course that IS something that could drop during the release candidate cycle. You may want to explore why the lookup_path is taking so long, no matter how you drive the update export interfaces, a long delay in that will result in a significant exposure where your exports are in flux. Note that the V4 dynamic export management via SIGHUP is significantly improved, allowing exports to be removed (if an export is no longer in the config, it will be removed) and additional parameters including Pseudo capable of being modified. Frank From: Sandeep Nashikkar via Devel [mailto:devel@lists.nfs-ganesha.org] Sent: Tuesday, October 12, 2021 8:22 AM To: devel(a)lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] ganesha_mgr add_export command returning premature success when underlying storage is slow Hello We are seeing issue as following: 1. We are using our own FSAL with ganesha version 2.8.2 which eventually performs operation on underlying storage through a wrapper layer. 2. We perform add_export programmatically when required. When add_export command tries to lstat, sometimes the underlying storage takes time to return the attributes. Here is the stack where it gets stuck for some time: #5 0x00007fdc9d24ea0f in lookup_path () from /usr/lib64/ganesha/libfsaltdfs.so #6 0x000000000053f719 in mdcache_lookup_path (exp_hdl=0x7fdbfa43d900, path=0x7fdbfa40f200 "/Chk1234", handle=0x7fdbfc0daac8, attrs_out=0x0) at /usr/src/debug/nfs-gan esha-2.6.3/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1697 #7 0x0000000000504454 in init_export_root (export=0x7fdbfa435448) at /usr/src/debug/nfs-ganesha-2.6.3/support/exports.c:2253 #8 0x00000000005029c2 in export_commit_common (node=0x7fdbfa4331a0, link_mem=0x0, self_struct=0x7fdbfa435448, err_type=0x7fdbfc0db160, commit_type=add_export) at /us r/src/debug/nfs-ganesha-2.6.3/support/exports.c:1235 #9 0x0000000000502e27 in add_export_commit (node=0x7fdbfa4331a0, link_mem=0x0, self_struct=0x7fdbfa435448, err_type=0x7fdbfc0db160) at /usr/src/debug/nfs-ganesha-2.6 .3/support/exports.c:1351 #10 0x000000000055832b in proc_block (node=0x7fdbfa4331a0, item=0x7e51a8 <add_export_param+8>, link_mem=0x0, err_type=0x7fdbfc0db160) at /usr/src/debug/nfs-ganesha-2. 6.3/config_parsing/config_parsing.c:1362 #11 0x0000000000559116 in load_config_from_node (tree_node=0x7fdbfa4331a0, conf_blk=0x7e51a0 <add_export_param>, param=0x0, unique=false, err_type=0x7fdbfc0db160) at /usr/src/debug/nfs-ganesha-2.6.3/config_parsing/config_parsing.c:1862 #12 0x0000000000518d42 in gsh_export_addexport (args=0x7fdbfc0db220, reply=0x7fdc97bf5180, error=0x7fdbfc0db270) at /usr/src/debug/nfs-ganesha-2.6.3/support/export_mg r.c:1038 #13 0x000000000055330b in dbus_message_entrypoint (conn=0x7fdc97aaa0c0, msg=0x7fdbfa42a440, user_data=0x7e5ff0 <export_interfaces>) at /usr/src/debug/nfs-ganesha-2.6. 3/dbus/dbus_server.c:564 #14 0x00007fdc9ca50276 in _dbus_object_tree_dispatch_and_unlock () from /lib64/libdbus-1.so.3 #15 0x00007fdc9ca41b29 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3 #16 0x00007fdc9ca41e42 in _dbus_connection_read_write_dispatch () from /lib64/libdbus-1.so.3 #17 0x0000000000553ed9 in gsh_dbus_thread (arg=0x0) at /usr/src/debug/nfs-ganesha-2.6.3/dbus/dbus_server.c:796 #18 0x00007fdc9b429e25 in start_thread () from /lib64/libpthread.so.0 #19 0x00007fdc9aae6bad in clone () from /lib64/libc.so.6 3. Despite the lstat getting stuck, add_export command returns prematurely in 30-40 seconds or so and return code is success. This is not expected. 4. This causes subsequent mount to fail since the export is not actually ready for the mount (init_export_root not being complete) Can someone help here to understand why dbus interface returns success? Is this known issue? How can we fix this behavior? Can we rather have a library interface to create/delete/update exports rather than relying on ganesha_mgr python script and dbus interface? Thanks Sandeep

1 0