March 2020 - Devel - NFS Ganesha List Archives

nfs-ganesha version compatible with gluster 5.9
by Jordan Smith 11 Mar '20

11 Mar '20

I am running ganesha 2.7.6 on Ubuntu-bionic with gluster version 5.9. I noticed for ganesha 2.8 there is a dependency for gluster 6 listed. Can version 2.8 or 3 be installed on a 5.X gluster system. I would like to upgrade to address a memory leak, but not sure if I need to upgrade the gluster cluster to use the newer version. Thanks for the help.

1 0

chown on a file with 777 permission does not work for any non-root user, not even the owner of the file
by des＠vmware.com 11 Mar '20

11 Mar '20

I have NFSv3 mount on linux client and trying to change the owner of the file: [root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error : 2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user) if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; } So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here: 2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check) if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; } if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; } access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.

5 7

FSAL loading RTLD_DEEPBIND and LD_PRELOAD
by Olivier Garaud 11 Mar '20

11 Mar '20

Hi, I'm wondering about the way Ganesha loads the FSAL in load_fsal we have > #if defined(LINUX) && !defined(SANITIZE_ADDRESS) > dl = dlopen(path, RTLD_NOW | RTLD_LOCAL | RTLD_DEEPBIND); > #elif defined(FREEBSD) || defined(SANITIZE_ADDRESS) > dl = dlopen(path, RTLD_NOW | RTLD_LOCAL); > #endif > On my system Ganesha is built with jemalloc but my FSAL is not (it's not using the same build chain) My FSAL is using malloc_usable_size. Ganesha does not use this symbol so it is resolved during dlopen. Because the RTLD_DEEPBIND flag is used, the libc version of malloc_usable_size is instead of the jemalloc one which ultimately leads to a crash. I could make sure both are built with the same allocator but this also happens when I try to dynamically change the memory allocator (LD_PRELOAD tcmalloc). Looking to the history (back in 2012) the RTLD_DEEPBIND flags has been introduced / removed and finally kept. Can somebody remember the reason why it is needed ? Did someone else had this kind of issue with LD_PRELOAD ? Thanks for your help, Regards, Olivier

3 3

Change in ...nfs-ganesha[next]: Fix Ganesha crash by sending stats
by Sachin Punadikar (GerritHub) 11 Mar '20

11 Mar '20

Sachin Punadikar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/487038 ) Change subject: Fix Ganesha crash by sending stats ...................................................................... Fix Ganesha crash by sending stats "ganesha_stats" with option client_all_ops sends stats for client specific ops, but only if they are non-zero. In case if "reset" operation was conducted, and there is no further activity by that client, then no stats would be sent, leading to crash of Ganesha in DBUS library code. To avoid this, work-around is opted in which stats for the first operation of that protocol will be always sent across. This will avoid the crash. Change-Id: Iec81e27d23459374062434b64f2273f97e548e86 Signed-off-by: Sachin Punadikar <psachin(a)in.ibm.com> --- M src/support/server_stats.c 1 file changed, 28 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/38/487038/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/487038 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: Iec81e27d23459374062434b64f2273f97e548e86 Gerrit-Change-Number: 487038 Gerrit-PatchSet: 1 Gerrit-Owner: Sachin Punadikar <psachin(a)in.ibm.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: Set no_cleanup=true prior to calling fsal_open2()/fsal_reopen2()
by Madhu Thorat (GerritHub) 11 Mar '20

11 Mar '20

Madhu Thorat has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/487024 ) Change subject: Set no_cleanup=true prior to calling fsal_open2()/fsal_reopen2() ...................................................................... Set no_cleanup=true prior to calling fsal_open2()/fsal_reopen2() After a "state_lock" is held, if a FSALs open2(..)/reopen2(..) gets called and if it fails with ESTALE then there is a possibility of having a crash as we would try to take the same "state_lock" again in state_wipe_file(..). To avoid this we now set state_hdl->no_cleanup=true after holding a "state_lock". Change-Id: I99c611c14123266a5056c24c9a26e724476d09dd Signed-off-by: Madhu Thorat <madhu.punjabi(a)in.ibm.com> --- M src/Protocols/NFS/nfs4_op_open.c M src/Protocols/NFS/nfs4_op_open_downgrade.c 2 files changed, 24 insertions(+), 23 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/24/487024/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/487024 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: I99c611c14123266a5056c24c9a26e724476d09dd Gerrit-Change-Number: 487024 Gerrit-PatchSet: 1 Gerrit-Owner: Madhu Thorat <madhu.punjabi(a)in.ibm.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: scripts/systemd: .include is deprecated, use drop-in .conf file
by Kaleb KEITHLEY (GerritHub) 10 Mar '20

10 Mar '20

Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486938 ) Change subject: scripts/systemd: .include is deprecated, use drop-in .conf file ...................................................................... scripts/systemd: .include is deprecated, use drop-in .conf file https://github.com/nfs-ganesha/nfs-ganesha/issues/547 It seems the .include was for the "Conflicts=..." line. Some sites on the web say that for a Conflicts line you need to override the entire contents of the file. Systemd documentation is generally poor IMO, and there's little to no documentation about drop-in files in general and nothing about how to handle Conflicts= so this is my best guess at a drop-in file. Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com> Change-Id: I1b701406836d4bd4268b981913b34c7f04311fa2 --- M src/nfs-ganesha.spec-in.cmake A src/scripts/systemd/nfs-ganesha-lock.service.debian10 A src/scripts/systemd/nfs-ganesha-lock.service.el8 A src/scripts/systemd/rpc-statd.conf.debian10 A src/scripts/systemd/rpc-statd.conf.el8 5 files changed, 92 insertions(+), 46 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/38/486938/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486938 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: I1b701406836d4bd4268b981913b34c7f04311fa2 Gerrit-Change-Number: 486938 Gerrit-PatchSet: 1 Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com> Gerrit-MessageType: newchange

1 0

Announce Push of V4-dev.8
by Frank Filz 06 Mar '20

06 Mar '20

Branch next Tag:V4-dev.8 Merge Highlights * MDCACHE - Unref chunk when not populating * Supporting protocol update as part of UpdateExport * FSAL: Skip additional file system types Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> Contents: 8efea5d Frank S. Filz V4-dev.8 04bab1c Frank S. Filz FSAL: Skip additional file system types 7894fd1 Sriram Patil Supporting protocol update as part of UpdateExport 9c4cdcf Daniel Gryniewicz MDCACHE - Unref chunk when not populating

1 0

Change in ...nfs-ganesha[next]: WIP: Fix entry->lru.refcnt
by Malahal (GerritHub) 05 Mar '20

05 Mar '20

Malahal has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486543 ) Change subject: WIP: Fix entry->lru.refcnt ...................................................................... WIP: Fix entry->lru.refcnt Change-Id: I4fbc2bd6bff6c08338af52595a9bea66969f8467 Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com> --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_hash.h M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c 3 files changed, 40 insertions(+), 38 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/43/486543/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486543 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: I4fbc2bd6bff6c08338af52595a9bea66969f8467 Gerrit-Change-Number: 486543 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal <malahal(a)gmail.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: MDCACHE - Unref chunk when not populating
by Daniel Gryniewicz (GerritHub) 05 Mar '20

05 Mar '20

Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486532 ) Change subject: MDCACHE - Unref chunk when not populating ...................................................................... MDCACHE - Unref chunk when not populating When we're progressing to the next chunk, and it's already there (i.e. we don't need to populate it), we need to drop our ref on the previous chunk. Change-Id: I73b03510b4cf3cf311b64b4462d2680b2b21a25c Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com> --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c 1 file changed, 4 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/32/486532/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486532 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: I73b03510b4cf3cf311b64b4462d2680b2b21a25c Gerrit-Change-Number: 486532 Gerrit-PatchSet: 1 Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com> Gerrit-MessageType: newchange

1 0

Change in ...nfs-ganesha[next]: Lock Owner hash table should account for its related owner
by Trishali Nayar (GerritHub) 05 Mar '20

05 Mar '20

Trishali Nayar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486514 ) Change subject: Lock Owner hash table should account for its related owner ...................................................................... Lock Owner hash table should account for its related owner The lock owner has an open-owner under which the lock owner was created. That should be taken into account for hashing and comparing the lock owners. Change-Id: I0c5cf1e2fdf891a0136accfed87d900dae17ff3b Signed-off-by: Trishali Nayar <ntrishal(a)in.ibm.com> --- M src/SAL/nfs4_owner.c 1 file changed, 27 insertions(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/14/486514/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/486514 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: I0c5cf1e2fdf891a0136accfed87d900dae17ff3b Gerrit-Change-Number: 486514 Gerrit-PatchSet: 1 Gerrit-Owner: Trishali Nayar <ntrishal(a)in.ibm.com> Gerrit-MessageType: newchange

1 0