March 2022 - Devel - Nfs Ganesha List Archives

Change in ...nfs-ganesha[next]: Allow EXPORT pseudo path to be changed during export update

by Frank Filz (GerritHub)

Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/490334 ) Change subject: Allow EXPORT pseudo path to be changed during export update ...................................................................... Allow EXPORT pseudo path to be changed during export update This also fully allows adding or removing NFSv4 support from an export since we can now handle the PseudoFS swizzing that occurs. Note that an explicit PseudoFS export may be removed or added, though you can not change it from export_id 0 because we currently don't allow changing the export_id. Note that this patch doesn't handle DBUS add or remove export though that is an option to improve. I may add them to this patch (it wouldn't be that hard) but I want to get this reviewed as is right now. There are implications to a client of changing the PseudoFS. I have tested moving an export in the PseudoFS with a client mounted. The client will be able to continue accessing the export, though it may see an ESTALE error if it navigates out of the export. The current working directory will go bad and the pwd comment will fail indicating a disconnected mount. I have also seen referencing .. from the root of the export wrapping around back to the root (I believe this is how disconnected mounts are set up). FSAL_PSEUDO lookups and create handles (PUTFH or any use of an NFSv3 handle where the inode isn't cached) which fail during an export update are instead turned into ERR_FSAL_DELAY which turns into NFS4ERR_DELAY or NFS3ERR_JUKEBOX to force the client to retry under the completed update. Change-Id: I507dc17a651936936de82303ff1291677ce136be Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> --- M src/FSAL/FSAL_PSEUDO/handle.c M src/MainNFSD/libganesha_nfsd.ver M src/Protocols/NFS/nfs4_pseudo.c M src/include/export_mgr.h M src/include/nfs_proto_functions.h M src/support/export_mgr.c M src/support/exports.c 7 files changed, 560 insertions(+), 203 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/34/490334/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/490334 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: I507dc17a651936936de82303ff1291677ce136be Gerrit-Change-Number: 490334 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com> Gerrit-MessageType: newchange

2 months

2
2
0 / 0

Question on empty ACL representation in the FSAL - issue with Ganesha 4.0

by Vaillant Romain

Hello, I am trying to upgrade our FSAL from ganesha 3.4 to 4.0.2 but I got into trouble regarding ACLs. It is not clear to me how an empty ACL should be represented / returned from the FSAL. Currently our FSAL implementation assigns NULL to fsal_attrlist.acl and the valid_mask with ATTR_ACL (getattrs). It seemed to work in 3.4 but in 4.0, nfs4_getfacl fails on a not supported error (on RHEL8, NFS4.0). I looked at some NFS traces, with ganesha 3.4 the response is ultimately translated to a a NFS_OK with the GETATTR attr_mask containing the ACL flag. In ganesha 4.0.2 the reply is NFS_OK but it doesn't contains any attr_mask. Does anyone know if it is a missuse of the FSAL API on our side ? What is the correct way to handle empty ACL ?

2 years

1
0
0 / 0

Change in ...nfs-ganesha[next]: FSAL: Fix regression in POSIX ACL mapping code

by Martin Schwenke (GerritHub)

Martin Schwenke has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/535378 ) Change subject: FSAL: Fix regression in POSIX ACL mapping code ...................................................................... FSAL: Fix regression in POSIX ACL mapping code get_entry() is called for all entries, including those with tag ACL_USER_OBJ and ACL_GROUP_OBJ. However, acl_set_qualifier(3) will return EINVAL if: The value of the tag type in the ACL entry referenced by the argument entry_d is neither ACL_USER nor ACL_GROUP. This was OK until commit 76692cd79f31bdd097cda4503de7df956e42cecd insisted that acl_set_qualifier(3) should succeed. Now, get_entry() fails for entries tagged ACL_USER_OBJ and ACL_GROUP_OBJ. The failure mode is quite spectacular, with corresponding calls to isdeny() returning true in fsal_acl_2_posix_acl(), causing allow ACEs for ACL_USER_OBJ and ACL_GROUP_OBJ not to be generated. Make the call to acl_set_qualifier(3) conditional on supported tags. Signed-off-by: Martin Schwenke <mschwenke(a)ddn.com> Change-Id: Id401b0608212a66eb717eaec8896c5ccf006b990 --- M src/FSAL/posix_acls.c 1 file changed, 33 insertions(+), 4 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/78/535378/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/535378 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: Id401b0608212a66eb717eaec8896c5ccf006b990 Gerrit-Change-Number: 535378 Gerrit-PatchSet: 1 Gerrit-Owner: Martin Schwenke <martin(a)meltin.net> Gerrit-MessageType: newchange

2 years

1
0
0 / 0

Change in ...nfs-ganesha[next]: FSAL_RGW: fix readdir overflow with incorrect offset(cookie)

by vicente (GerritHub)

vicente has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/535360 ) Change subject: FSAL_RGW: fix readdir overflow with incorrect offset(cookie) ...................................................................... FSAL_RGW: fix readdir overflow with incorrect offset(cookie) - Should pass the last folder name pointer for offset Change-Id: I73d61995f6aa63c37d54f9b25bb74db7dec7acf8 Signed-off-by: Vicente Cheng <vicente_cheng(a)bigtera.com> --- M src/FSAL/FSAL_RGW/handle.c 1 file changed, 19 insertions(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/60/535360/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/535360 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: I73d61995f6aa63c37d54f9b25bb74db7dec7acf8 Gerrit-Change-Number: 535360 Gerrit-PatchSet: 1 Gerrit-Owner: vicente <freeze.bilsted(a)gmail.com> Gerrit-MessageType: newchange

2 years

1
0
0 / 0

Change in ...nfs-ganesha[next]: Free not only first entry Currently lru_reap_impl only check whether ...

by liyinshu (GerritHub)

liyinshu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/535308 ) Change subject: Free not only first entry Currently lru_reap_impl only check whether first entry of lq->q can be reclaimable. But sometimes, the first entry can not be reclaimed for a long time, then we have to malloc several million new mdcache_entry_t. The size of mdcache_entry_t is 1200 bytes, then the memory of mdcache_entry_t is serveral GB, which should be improved. So we check all the entries of lq_q, whether can be reclaimed, to avoid malloc so many mdcache_entry_t. ...................................................................... Free not only first entry Currently lru_reap_impl only check whether first entry of lq->q can be reclaimable. But sometimes, the first entry can not be reclaimed for a long time, then we have to malloc several million new mdcache_entry_t. The size of mdcache_entry_t is 1200 bytes, then the memory of mdcache_entry_t is serveral GB, which should be improved. So we check all the entries of lq_q, whether can be reclaimed, to avoid malloc so many mdcache_entry_t. Change-Id: If733ff96f88cd660b43cf3cfbf22680ef5dcf6e7 Signed-off-by: liyinshu <liyinshu(a)bytedance.com> Change-Id: I85a842bc6b5f9dc6dc106b03d871d823fa7b2dae --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c 1 file changed, 99 insertions(+), 66 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/08/535308/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/535308 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: I85a842bc6b5f9dc6dc106b03d871d823fa7b2dae Gerrit-Change-Number: 535308 Gerrit-PatchSet: 1 Gerrit-Owner: liyinshu <liyinshu(a)bytedance.com> Gerrit-MessageType: newchange

2 years, 1 month

1
0
0 / 0

Change in ...nfs-ganesha[next]: systemd: eliminate a (beign?) error when enabling nfs-ganesha.service

by Kaleb KEITHLEY (GerritHub)

Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/534775 ) Change subject: systemd: eliminate a (beign?) error when enabling nfs-ganesha.service ...................................................................... systemd: eliminate a (beign?) error when enabling nfs-ganesha.service See https://bugzilla.redhat.com/show_bug.cgi?id=1907534 (private) Enabling ganesha, e.g. with `systemctl enable nfs-ganesah` results in the following error msg: ... The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. But the nfs-ganesha.service file does have an [Install] section, and it was not apparent that the error is because, as explained by one of the systemd devs, the nfs-ganesha-lock.service file does not have an [Install] section. Change-Id: Iea168b14feb4426e352b1ea88140b17aa47efb26 Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com> --- M src/scripts/systemd/nfs-ganesha-lock.service.el8 M src/scripts/systemd/nfs-ganesha-lock.service.debian10 2 files changed, 39 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/75/534775/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/534775 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: Iea168b14feb4426e352b1ea88140b17aa47efb26 Gerrit-Change-Number: 534775 Gerrit-PatchSet: 1 Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com> Gerrit-MessageType: newchange

2 years, 1 month

1
0
0 / 0

NFS Ganesha 4.0.2: Build issue on RHEL8 with find_package(Python)

by Vaillant Romain

Hello, I've got a bit in trouble trying to build ganesha (4.0.2) with python admin tools on RHEL8, the search for the python interpreter fails (it does have python3.6 available in /usr/bin). I am not sure if it is problem in the CMakeLists.txt configuration or an environment / cmake problem (as I am not familiar with cmake). I had a similar issue on Centos7, but I got it solved with Python_ROOT_PATH set to /usr/bin, this solution doesn't work at all on RHEL8 and I didn't find any other. The only difference that I currently see is that on centos7 cmake is 3.17.5 and on rhel8 cmake is 3.20.2. And AFAIK, the FindPython.cmake changed quite a bit in between. If I put back the old FindPython module on RHEL8, the python package is found. Trying to debug the search (find_program), I found that the NAMES are always empty e.g: VAR: _Python_EXECUTABLE NAMES: Documentation: Path to a program. Framework Only Search Frameworks: 0 Search Frameworks Last: 0 Search Frameworks First: 0 AppBundle Only Search AppBundle: 0 Search AppBundle Last: 0 Search AppBundle First: 0 CMAKE_FIND_USE_CMAKE_PATH: 1 CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH: 1 CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH: 1 CMAKE_FIND_USE_CMAKE_SYSTEM_PATH: 1 I thought that it was a configuration problem on my side, but after digging a bit it seems that the cmake_parse_arguments (PARSE_ARGV ...) gets misinterpreted and uses PARSE_ARGV as a prefix... But it seems a bit too big to be true. Is this a known problem ? Does someone has any insight / pointers on this ?

2 years, 1 month

3
3
0 / 0

Implementing NFSv4 -> POSIX ACL mapping in FSAL_VFS

by Martin Schwenke

I'm planning on implementing NFSv4 -> POSIX ACL mapping in FSAL_VFS. My main target is Lustre. I can see several ways of approaching this, most of them not Lustre-specific, so I thought I'd throw some questions out here, gather opinions and then attempt the implementation. I'm relatively new to the NFS Ganesha codebase, having dived into a couple of areas in recent months. However, I have quite solid open source experience, primarily in Samba. I was hoping to post a proof-of-concept implementation but there are too many decisions to make that result in quite different code and different amounts of code... so I'll ask questions first. :-) There are several parts to this: * Coding vfs_set_acl() and vfs_get_acl() functions, or similar * Plugging set_acl()/get_acl() functions in via setattr()/getattr() functions * Enabling calls to test_access() and similar Coding vfs_set_acl() and vfs_get_acl() functions ------------------------------------------------ This looks quite straightforward, depending on where it is implemented. FSAL_GLUSTER & FSAL_CEPH provide good examples - I have a proof-of-concept implementation of this. Use fsal_acl_2_posix_acl()/posix_acl_2_fsal_acl() to do the translation. Use libacl to read/write the POSIX ACLs, or existing FSAL_VFS code to read/write extended attributes and use xattr_2_posix_acl()/posix_acl_2_xattr() to translate them. At the moment I've done the latter because I followed the FSAL_CEPH example. I'd like advice on whether using libacl is likely to be acceptable, since it should mean less code. Plugging set_acl()/get_acl() functions in via setattr()/getattr() functions --------------------------------------------------------------------------- I can see 2 main options for doing this: * Inline in FSAL_VFS/file.c, in vfs_setattr2() and probably vfs_getattr() If a "global" FSAL_VFS implementation is acceptable then this seems like the most straightforward way. * In the vfs subfsal, via sub_ops->{getattrs,setattrs} This seems like the cleanest way of structuring it. If we go this route then I hope that libacl is acceptable, since it will help avoid factoring out the extended attribute code to avoid layering violations. This could even go further "down" into the Lustre subfsal, but that doesn't seem necessary, since everything sane seems to implement POSIX ACLs, so everyone can share the joy (and the bugs ;-). Enabling calls to test_access() and similar ------------------------------------------- There are sections of code currently enclosed in: #ifdef ENABLE_VFS_DEBUG_ACL Most of that code looks to be generic, so it should work with a real ACL implementation too. My first guess is that I could change nearly all of these to: #ifdef ENABLE_VFS_ACL or similar, and have ENABLE_VFS_ACL defined when either ENABLE_VFS_DEBUG_ACL or (say) ENABLE_VFS_POSIX_ACL is defined. Please let me know whether any of this makes sense... and which way I should go for the major decisions... :-) Thanks! peace & happiness, martin

2 years, 1 month

3
2
0 / 0

Change in ...nfs-ganesha[next]: fix add export failed and return already active

by bjfhdhhaha (GerritHub)

bjfhdhhaha has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/534414 ) Change subject: fix add export failed and return already active ...................................................................... fix add export failed and return already active Change-Id: I9fcfe2b4f6f520e2183db0dbbe16b9fd690f3e8d Signed-off-by: bjfhdhhaha <1453769042(a)qq.com> --- M src/config_parsing/config_parsing.c 1 file changed, 16 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/14/534414/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/534414 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: I9fcfe2b4f6f520e2183db0dbbe16b9fd690f3e8d Gerrit-Change-Number: 534414 Gerrit-PatchSet: 1 Gerrit-Owner: bjfhdhhaha <1453769042(a)qq.com> Gerrit-MessageType: newchange

2 years, 1 month

1
0
0 / 0

Change in ...nfs-ganesha[next]: Exit immediately when LogFatal

by liyinshu (GerritHub)

liyinshu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/534124 ) Change subject: Exit immediately when LogFatal ...................................................................... Exit immediately when LogFatal Change-Id: If97fe921c9729521029d0e23ed7fe9eb5272a825 Signed-off-by: liyinshu <liyinshu(a)bytedance.com> --- M src/log/log_functions.c 1 file changed, 11 insertions(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/24/534124/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/534124 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: If97fe921c9729521029d0e23ed7fe9eb5272a825 Gerrit-Change-Number: 534124 Gerrit-PatchSet: 1 Gerrit-Owner: liyinshu <liyinshu(a)bytedance.com> Gerrit-MessageType: newchange

2 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

Devel March 2022