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, 4 weeks
Help needed on FD
by Alok Sinha
FD created at below path does not have correct link in /proc/self/fd.
With vfs_readlink_by_handle , I can get a relative path but cannot get the
absolute path of the FD.
I need a suggestion for one of the below to get around a production bug:
- How to get the full path of the FD?
- How to get the parent vfs_fsal_obj_handle?
- Anyway to bypass this flow by changing any config file?
#0 vfs_create_handle (exp_hdl=0x55801aca22c0, hdl_desc=0x7f93889b1600,
handle=0x7f93889b13f8, attrs_out=0x7f93889b1430)
at /home/alok/pub/splfs-cache-2.8.3/src/FSAL/FSAL_VFS/handle.c:2020
#1 0x00007f94a1f0e13b in mdcache_locate_host (fh_desc=0x7f93889b1600,
export=0x55801aca1f20, entry=0x7f93889b1578, attrs_out=0x0)
at
/home/alok/pub/splfs-cache-2.8.3/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:1109
#2 0x00007f94a1f02455 in mdcache_create_handle (exp_hdl=0x55801aca1f20,
fh_desc=0x7f93889b1600, handle=0x7f93889b15d8, attrs_out=0x0)
at
/home/alok/pub/splfs-cache-2.8.3/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1613
#3 0x00007f94a1ec5ead in nfs4_mds_putfh (data=0x7f93201119e0)
at
/home/alok/pub/splfs-cache-2.8.3/src/Protocols/NFS/nfs4_op_putfh.c:211
#4 0x00007f94a1ec60d3 in nfs4_op_putfh (op=0x7f93201186d0,
data=0x7f93201119e0, resp=0x7f932010ab20)
at
/home/alok/pub/splfs-cache-2.8.3/src/Protocols/NFS/nfs4_op_putfh.c:281
#5 0x00007f94a1ea96ae in process_one_op (data=0x7f93201119e0,
status=0x7f93889b1b48)
at
/home/alok/pub/splfs-cache-2.8.3/src/Protocols/NFS/nfs4_Compound.c:920
#6 0x00007f94a1eaa8c5 in nfs4_Compound (arg=0x7f9320138d78,
req=0x7f93201385a0, res=0x7f9320106840)
at
/home/alok/pub/splfs-cache-2.8.3/src/Protocols/NFS/nfs4_Compound.c:1329
#7 0x00007f94a1de8567 in nfs_rpc_process_request (reqdata=0x7f93201385a0)
---Type <return> to continue, or q <return> to quit---
at
/home/alok/pub/splfs-cache-2.8.3/src/MainNFSD/nfs_worker_thread.c:1484
#8 0x00007f94a1de8854 in nfs_rpc_valid_NFS (req=0x7f93201385a0)
at
/home/alok/pub/splfs-cache-2.8.3/src/MainNFSD/nfs_worker_thread.c:1591
#9 0x00007f94a13b6faf in svc_vc_decode (req=0x7f93201385a0)
at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/svc_vc.c:829
#10 0x00007f94a13b3225 in svc_request (xprt=0x7f9320000ce0,
xdrs=0x7f9320066260)
at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/svc_rqst.c:793
#11 0x00007f94a13b6ec0 in svc_vc_recv (xprt=0x7f9320000ce0)
at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/svc_vc.c:802
#12 0x00007f94a13b31a5 in svc_rqst_xprt_task (wpe=0x7f9320000f00)
at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/svc_rqst.c:774
#13 0x00007f94a13bcab0 in work_pool_thread (arg=0x7f9218003340)
at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/work_pool.c:184
#14 0x00007f94a1badea5 in start_thread () from /lib64/libpthread.so.0
#15 0x00007f94a16ce9fd in clone () from /lib64/libc.so.6
--
Alok Sinha
www.spillbox.io
https://youtu.be/U-YupjLQ9bU
3 months, 2 weeks
[XS] Change in ...nfs-ganesha[next]: build: Fix developer warning for LSB module
by Martin Schwenke (GerritHub)
Martin Schwenke has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/554766?usp=email )
Change subject: build: Fix developer warning for LSB module
......................................................................
build: Fix developer warning for LSB module
CMake Warning (dev) at /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to `find_package_handle_standard_args`
(LSB_RELEASE) does not match the name of the calling package (LSB). This
can lead to problems in calling code that expects `find_package` result
variables (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/modules/FindLSB.cmake:85 (find_package_handle_standard_args)
CMakeLists.txt:1632 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
Rename the module to LSBRelease and make that the first argument to
find_package_handle_standard_args().
Other options are:
* Pass LSB as the first argument. This just seems confusing.
* Rename the module to LSB_RELEASE. Given that there are no cmake
modules with names containing underscores, this doesn't seem like
the right solution.
Signed-off-by: Martin Schwenke <mschwenke(a)ddn.com>
Change-Id: If0e3c80378db8aa97e8f0b6f69d91ef0f8201e3f
---
M src/CMakeLists.txt
R src/cmake/modules/FindLSBRelease.cmake
2 files changed, 2 insertions(+), 2 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/66/554766/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/554766?usp=email
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: If0e3c80378db8aa97e8f0b6f69d91ef0f8201e3f
Gerrit-Change-Number: 554766
Gerrit-PatchSet: 1
Gerrit-Owner: Martin Schwenke <martin(a)meltin.net>
Gerrit-MessageType: newchange
11 months, 3 weeks
[L] Change in ...nfs-ganesha[next]: build: Fix Python detection
by Martin Schwenke (GerritHub)
Martin Schwenke has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/554765?usp=email )
Change subject: build: Fix Python detection
......................................................................
build: Fix Python detection
Commit c43049fc42b0a1d39b48ddbf93af56223ba5f9ee introduced copies of
several cmake modules, which are now breaking Python detection. The
commit message does not give details of benefits of these versions of
the modules. It is unclear if they were different to the upstream
cmake modules at the time and this can't be resolved without an
archaeological dig. Whatever the case, the modules have almost
certainly been improved upstream to work around the reason for their
addition here.
Just delete the duplicate modules introduced by the above commit.
This leaves src/cmake/modules/FindGTest.cmake as the only apparent
duplicate module.
Note that this change introduces a developer warning:
CMake Warning (dev) at /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to `find_package_handle_standard_args`
(LSB_RELEASE) does not match the name of the calling package (LSB). This
can lead to problems in calling code that expects `find_package` result
variables (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/modules/FindLSB.cmake:85 (find_package_handle_standard_args)
CMakeLists.txt:1632 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
Given that this is only a warning, this can be fixed in a subsequent
commit.
Signed-off-by: Martin Schwenke <mschwenke(a)ddn.com>
Change-Id: I0cb1fb4d3dd9674d52720095961ed6b56dda6c45
---
D src/cmake/modules/CMakeParseArguments.cmake
D src/cmake/modules/FindPackageHandleStandardArgs.cmake
D src/cmake/modules/FindPackageMessage.cmake
D src/cmake/modules/FindPkgConfig.cmake
4 files changed, 0 insertions(+), 898 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/65/554765/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/554765?usp=email
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: I0cb1fb4d3dd9674d52720095961ed6b56dda6c45
Gerrit-Change-Number: 554765
Gerrit-PatchSet: 1
Gerrit-Owner: Martin Schwenke <martin(a)meltin.net>
Gerrit-MessageType: newchange
11 months, 3 weeks
[S] Change in ...nfs-ganesha[next]: GPFS: fix 40 byte sized old file handles
by Name of user not set (GerritHub)
Attention is currently required from: Malahal.
Hello Malahal,
I'd like you to do a code review.
Please visit
https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/554760?usp=email
to review the following change.
Change subject: GPFS: fix 40 byte sized old file handles
......................................................................
GPFS: fix 40 byte sized old file handles
Some versions may have returned 40 byte sized file handles. Make them
same as 48 byte sized file handles to avoid multiple entries in the
object cache for the same file system object.
Change-Id: I242faa62cfc3c5d88db86a1096ef4720ce4c6590
Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com>
(cherry picked from commit 706e5dce49d7bbb07ea005d1b74eada8b0f1a761)
---
M src/FSAL/FSAL_GPFS/handle.c
1 file changed, 13 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/60/554760/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/554760?usp=email
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: I242faa62cfc3c5d88db86a1096ef4720ce4c6590
Gerrit-Change-Number: 554760
Gerrit-PatchSet: 1
Gerrit-Owner: skmprabhu252(a)gmail.com
Gerrit-Reviewer: Malahal <malahal(a)gmail.com>
Gerrit-Attention: Malahal <malahal(a)gmail.com>
Gerrit-MessageType: newchange
11 months, 3 weeks
MDCache LRU management queries
by Gaurav Sharma
Hi Ganesha Team,
In MDCache we have two arrays named LRU and CHUNK_LRU to store the lru
entry in their respective queues.
For the CHUNK_LRU, the function lru_bump_chunk() will move the entry to MRU
of L1.
For LRU there is a function adjust_lru() which does the similar job.
Question : The function adjust_lru() is only called if the flag
is LRU_REQ_INITIAL and that is happening only during unexport.
1. Can you please suggest how the entries in LRU queue are moving to MRU
of the queue?
2. How LRU entries are moved from L2 to L1 queue? from L1 to L2 is done
by the background thread.
Regards,
Gaurav Sharma
12 months
Announce Push of V5.2
by Frank Filz
Branch next
Tag:V5.2
Merge Highlights
* Fix btrfs typo in log messages
* Fix cmake so USE_FSAL_CEPH_FS_NONBLOCKING_IO will be used
* Unlock work_mutex in fsal_complete_io only if we got it
* For async I/O the callback must create it's own op_context
* monitoring: C++ cleanup to build with userspace-rcu-14.0.0
* NLM: Fix NSM reference count double-decrement
* Multi-client same hostname issue - open owner refcount fix
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
9a84f015b Frank S. Filz V5.2
2aa4494cd Deepak Arumugam Sankara Subramanian Multi-client same hostname
issue - open owner refcount fix
8f6ee41cd Martin Schwenke NLM: Fix NSM reference count double-decrement
622d7f68b Kaleb S. KEITHLEY monitoring: C++ cleanup to build with
userspace-rcu-14.0.0
10389577b Frank S. Filz For async I/O the callback must create it's own
op_context
43d984e2c Frank S. Filz Unlock work_mutex in fsal_complete_io only if we got
it
ed66984ae Frank S. Filz CMake - actually do USE_FSAL_CEPH_FS_NONBLOCKING_IO
5a747e92a Frank S. Filz Change btfs to btrfs in two log messages
1 year
[M] Change in ...nfs-ganesha[next]: Pass failure to add clientid to recovery database back to client
by Frank Filz (GerritHub)
Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/553781?usp=email )
Change subject: Pass failure to add clientid to recovery database back to client
......................................................................
Pass failure to add clientid to recovery database back to client
Previously we would log an error, but leave the client with no
clue that it would not be able to reclaim state in the case of
a server failure.
The failure will be reported to the client as NFS4ERR_SERVERFAULT
on SET_CLIENDID_CONFIRM or CREATE_SESSION.
Change-Id: If68312abcd06ff5bcc010ebd84d1421717b839a3
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
---
M src/SAL/nfs4_clientid.c
M src/SAL/nfs4_recovery.c
M src/SAL/recovery/recovery_fs.c
M src/SAL/recovery/recovery_fs.h
M src/SAL/recovery/recovery_rados.h
M src/SAL/recovery/recovery_rados_kv.c
M src/SAL/recovery/recovery_rados_ng.c
M src/include/sal_data.h
M src/include/sal_functions.h
9 files changed, 74 insertions(+), 20 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/81/553781/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/553781?usp=email
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: If68312abcd06ff5bcc010ebd84d1421717b839a3
Gerrit-Change-Number: 553781
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>
Gerrit-MessageType: newchange
1 year
[M] Change in ...nfs-ganesha[next]: For async I/O the callback must create it's own op_context
by Frank Filz (GerritHub)
Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/553780?usp=email )
Change subject: For async I/O the callback must create it's own op_context
......................................................................
For async I/O the callback must create it's own op_context
We can't pass the orginal caller's op_context, it may still need it.
Just instantiate a simple op_context for the callback.
The callback op_context needs an export reference but we can take
it when we create the op_context because until the protocol callback
is made, we know the protocol request's op_context with its reference
for the export MUST still be valid.
Change-Id: I061c7eed8105b3283a243335b5ea63a86225b85b
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
---
M src/FSAL/FSAL_CEPH/handle.c
M src/FSAL/FSAL_MEM/mem_handle.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_file.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h
4 files changed, 98 insertions(+), 47 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/80/553780/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/553780?usp=email
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: I061c7eed8105b3283a243335b5ea63a86225b85b
Gerrit-Change-Number: 553780
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>
Gerrit-MessageType: newchange
1 year
