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
9 months, 3 weeks
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, 8 months
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, 8 months
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, 8 months
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, 8 months
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, 8 months
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, 8 months