October 2025 - Devel - Nfs Ganesha List Archives

Re: Clarification on delegation behavior for same-client conflicting OPEN

by Jeff Layton

On Thu, 2025-10-30 at 17:35 +0000, Suhas Athani via Devel wrote: > > Hello NFS community, > > We’re seeking clarification on server behavior for OPEN delegations when the same client issues a potentially conflicting OPEN on a file for which it already holds a delegation. > > Context and RFC references > > * > RFC 8881(10.4 Open Delegation) > - > “There must be no current OPEN conflicting with the requested delegation.” > - > “There should be no current delegation that conflicts with the delegation being requested.” > > * > RFC 8881(10.4.1 Open Delegation and Data Caching) > - > For delegation handling, READs/WRITEs without OPEN are treated as the functional equivalents of a corresponding type of OPEN, and the server “can use the client ID associated with the current session to determine if the operation has been done by the holder of the delegation (in which case, no recall is necessary) or by another client (in which case, the delegation must be recalled and I/O not proceed until the delegation is returned or revoked).” > > * > Historical reference: RFC 5661 (obsoleted by RFC 8881) carries the same sections 10.4 and 10.4.1 > Questions > 1) Same-client conflicting OPEN: > > * > If a client holds an OPEN_DELEGATE_READ on a file and then the same client issues an OPEN that requires write access (or otherwise conflicts), should the server: > * > > > > > - > Allow the OPEN to complete immediately without recalling the delegation (i.e., no recall necessary for same-client), per RFC 8881 10.4.1; or > > * > Recall the delegation anyway and delay the operation until DELEGRETURN? The Linux NFS server allows the open to complete, which I think has been the consensus around this point in earlier discussions. Basically, activity from the holder of a delegation is not considered "conflicting". That client presumably knows about any changes and can update its cache accordingly, so we don't need to recall the delegation in this case. > 2) OPEN_DELEGATE_WRITE symmetry: > > * > If a client holds an OPEN_DELEGATE_WRITE and then the same client issues an OPEN that requires read access (or otherwise changes share access/deny modes), should the server similarly allow the operation to proceed without recall, or recall and delay? WRITE delegations should probably have been called READ_WRITE. The Linux NFS server and the spec treat them as a superset of a READ delegation. So, opening the file for READ when you hold a WRITE deleg is not considered conflicting activity. > 3) Any updates since RFC 5661: > > * > Are there clarifications or consensus updates in RFC 8881 (vs. RFC 5661) or later documents that alter expected behavior in the same-client case? > > > Thank you in advance for your time and insights. Looking forward to your guidance and clarification on these points. > > Regards, > Suhas Athani > NFS-ganesha Team > > > > > _______________________________________________ > Devel mailing list -- devel(a)lists.nfs-ganesha.org > To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org -- Jeff Layton <jlayton(a)poochiereds.net>

2 weeks, 2 days

3
2
0 / 0

[S] Change in ...nfs-ganesha[next]: Fix data race and type mismatch in TCP DRC recycle queue length.

by Suhas Athani (GerritHub)

Suhas Athani has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225404?usp=email ) Change subject: Fix data race and type mismatch in TCP DRC recycle queue length. ...................................................................... Fix data race and type mismatch in TCP DRC recycle queue length. - Protect read of tcp_drc_recycle_qlen with drc_st_mtx in get_tcp_drc_recycle_qlen() to fix Coverity 583557 data race. - Change drc_st->tcp_drc_recycle_qlen type to uint32_t to match the API and usage. Change-Id: Id63f0340ed1b7cdeaaabc8309630d8dd23260886 Signed-off-by: Suhas Athani <Suhas.Athani(a)ibm.com> --- M src/RPCAL/nfs_dupreq.c 1 file changed, 8 insertions(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/04/1225404/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225404?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Id63f0340ed1b7cdeaaabc8309630d8dd23260886 Gerrit-Change-Number: 1225404 Gerrit-PatchSet: 1 Gerrit-Owner: Suhas Athani <Suhas.Athani(a)ibm.com>

3 weeks

1
0
0 / 0

[L] Change in ...nfs-ganesha[next]: Enhance header files to support both C and C++ compilation

by Name of user not set (GerritHub)

sragraha(a)redhat.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225402?usp=email ) Change subject: Enhance header files to support both C and C++ compilation ...................................................................... Enhance header files to support both C and C++ compilation This change standardizes the header interface, making it robust for use of both C and C++ source files, which is critical for prometheus .cc files usability. Change-Id: I489f99ce7d181cd2d4969f340e9691a5e2217e32 Signed-off-by: Sreedhar Agraharam <sragraha(a)redhat.com> --- M src/FSAL/FSAL_RGW/handle.c M src/include/9p.h M src/include/abstract_mem.h M src/include/common_utils.h M src/include/fsal.h M src/include/gsh_lttng/gsh_lttng.h M src/include/gsh_refstr.h M src/include/hashtable.h M src/include/log.h M src/include/nfs_fh.h M src/include/nfsacl.h M src/include/nfsv41.h M src/include/sal_data.h 13 files changed, 184 insertions(+), 114 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/02/1225402/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225402?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I489f99ce7d181cd2d4969f340e9691a5e2217e32 Gerrit-Change-Number: 1225402 Gerrit-PatchSet: 1 Gerrit-Owner: sragraha(a)redhat.com

3 weeks

1
0
0 / 0

[S] Change in ...nfs-ganesha[next]: clean up python build and install, including associated .spec fixes r...

by Kaleb KEITHLEY (GerritHub)

Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225399?usp=email ) Change subject: clean up python build and install, including associated .spec fixes rhbz#2405281 ...................................................................... clean up python build and install, including associated .spec fixes rhbz#2405281 Change-Id: If332ee9a387fd4a130dac61b8258b37360135607 Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com> --- M src/nfs-ganesha.spec-in.cmake M src/scripts/ganesha-top/CMakeLists.txt M src/scripts/ganeshactl/CMakeLists.txt M src/scripts/gpfs-epoch/CMakeLists.txt M src/scripts/gpfs-epoch/setup.py.in 5 files changed, 15 insertions(+), 23 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/99/1225399/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225399?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: If332ee9a387fd4a130dac61b8258b37360135607 Gerrit-Change-Number: 1225399 Gerrit-PatchSet: 1 Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com>

3 weeks, 1 day

1
0
0 / 0

Clarification on delegation behavior for same-client conflicting OPEN

by Suhas Athani

Hello NFS community, We’re seeking clarification on server behavior for OPEN delegations when the same client issues a potentially conflicting OPEN on a file for which it already holds a delegation. Context and RFC references * RFC 8881 (10.4 Open Delegation)<https://datatracker.ietf.org/doc/html/rfc8881#name-open-delegation> * “There must be no current OPEN conflicting with the requested delegation.” * “There should be no current delegation that conflicts with the delegation being requested.” * RFC 8881 (10.4.1 Open Delegation and Data Caching)<https://datatracker.ietf.org/doc/html/rfc8881#name-open-delegation-and-da...> * For delegation handling, READs/WRITEs without OPEN are treated as the functional equivalents of a corresponding type of OPEN, and the server “can use the client ID associated with the current session to determine if the operation has been done by the holder of the delegation (in which case, no recall is necessary) or by another client (in which case, the delegation must be recalled and I/O not proceed until the delegation is returned or revoked).” * Historical reference: RFC 5661 (obsoleted by RFC 8881) carries the same sections 10.4 and 10.4.1 Questions 1) Same-client conflicting OPEN: * If a client holds an OPEN_DELEGATE_READ on a file and then the same client issues an OPEN that requires write access (or otherwise conflicts), should the server: * * Allow the OPEN to complete immediately without recalling the delegation (i.e., no recall necessary for same-client), per RFC 8881 10.4.1; or * Recall the delegation anyway and delay the operation until DELEGRETURN? 2) OPEN_DELEGATE_WRITE symmetry: * If a client holds an OPEN_DELEGATE_WRITE and then the same client issues an OPEN that requires read access (or otherwise changes share access/deny modes), should the server similarly allow the operation to proceed without recall, or recall and delay? 3) Any updates since RFC 5661: * Are there clarifications or consensus updates in RFC 8881 (vs. RFC 5661) or later documents that alter expected behavior in the same-client case? Thank you in advance for your time and insights. Looking forward to your guidance and clarification on these points. Regards, Suhas Athani NFS-ganesha Team

3 weeks, 1 day

1
0
0 / 0

[S] Change in ...nfs-ganesha[next]: Fix rpm build error for GPFS FSAL

by Sachin Punadikar (GerritHub)

Sachin Punadikar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225224?usp=email ) Change subject: Fix rpm build error for GPFS FSAL ...................................................................... Fix rpm build error for GPFS FSAL Change-Id: I6d7d66338f273b8dedf4b4465a09112f198ad3b4 Signed-off-by: Sachin Punadikar <sachin.punadikar(a)ibm.com> --- M src/nfs-ganesha.spec-in.cmake 1 file changed, 4 insertions(+), 6 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/24/1225224/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225224?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I6d7d66338f273b8dedf4b4465a09112f198ad3b4 Gerrit-Change-Number: 1225224 Gerrit-PatchSet: 1 Gerrit-Owner: Sachin Punadikar <sachin.punadikar(a)ibm.com>

3 weeks, 2 days

1
0
0 / 0

[S] Change in ...nfs-ganesha[next]: Fix crash in NFS3 read when read_count is zero

by Xueqian Hu (GerritHub)

Xueqian Hu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225177?usp=email ) Change subject: Fix crash in NFS3 read when read_count is zero ...................................................................... Fix crash in NFS3 read when read_count is zero The crash happened because resok->data.iov was not initialized when read_count is 0. The code tried to access iov[0] but iov was NULL. We now initialize the iovec before checking if size is 0, ensuring iov always points to the iov0 field and preventing. Change-Id: I06f24b3e5c070a7515a24e492c713b5c9dec9ffd Signed-off-by: xueqian.hu <xh140312(a)outlook.com> --- M src/Protocols/NFS/nfs3_read.c 1 file changed, 9 insertions(+), 9 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/77/1225177/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225177?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I06f24b3e5c070a7515a24e492c713b5c9dec9ffd Gerrit-Change-Number: 1225177 Gerrit-PatchSet: 1 Gerrit-Owner: Xueqian Hu <xh140312(a)outlook.com>

3 weeks, 3 days

1
0
0 / 0

[S] Change in ...nfs-ganesha[next]: nfs3/reopen: Retry open if failed with EPERM

by Rafi KC (GerritHub)

Rafi KC has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225173?usp=email ) Change subject: nfs3/reopen: Retry open if failed with EPERM ...................................................................... nfs3/reopen: Retry open if failed with EPERM If an open request fails with EPERM or EACCES, it may be due to a permission change in the backend after the last access. When open flags were modified before the failure, retrying with the original flags helps avoid false failures caused by flag combinations. For example, combining O_RDONLY and O_WRONLY into O_RDWR may result in a permission denied error if write access is not allowed. Fixes: #1335 Change-Id: I196c597def36c1254dde5f2116ccebc31b3f8c11 Signed-off-by: Mohammed Rafi KC <rafi.kavungal(a)iternity.com> --- M src/FSAL/commonlib.c M src/include/FSAL/fsal_commonlib.h 2 files changed, 26 insertions(+), 5 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/73/1225173/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225173?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I196c597def36c1254dde5f2116ccebc31b3f8c11 Gerrit-Change-Number: 1225173 Gerrit-PatchSet: 1 Gerrit-Owner: Rafi KC <rafi.kavungal(a)iternity.com>

3 weeks, 3 days

1
0
0 / 0

[S] Change in ...nfs-ganesha[next]: Fix: Register NFS service using RADOS RECOVERY nodeid configuration

by Name of user not set (GerritHub)

sragraha(a)redhat.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225140?usp=email ) Change subject: Fix: Register NFS service using RADOS RECOVERY nodeid configuration ...................................................................... Fix: Register NFS service using RADOS RECOVERY nodeid configuration This change updates the NFS service registration logic to utilize the nodeid from the RADOS RECOVERY configuration. In Ceph clusters, the nodeid acts as the unique instance/daemon identifier for services. By registering the NFS service with its respective nodeid, we ensure that each service instance is properly recognized and managed within the cluster environment. Change-Id: Ib10aba74405df65490317f706a03149b9ba36370 Signed-off-by: Sreedhar Agraharam <sragraha(a)redhat.com> --- M src/SAL/recovery/recovery_rados_kv.c M src/config_parsing/conf_url_rados.c 2 files changed, 21 insertions(+), 21 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/40/1225140/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225140?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Ib10aba74405df65490317f706a03149b9ba36370 Gerrit-Change-Number: 1225140 Gerrit-PatchSet: 1 Gerrit-Owner: sragraha(a)redhat.com

3 weeks, 3 days

1
0
0 / 0

[S] Change in ...nfs-ganesha[next]: add fsal_private_op method in export_ops

by haihuayang (GerritHub)

haihuayang has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225129?usp=email ) Change subject: add fsal_private_op method in export_ops ...................................................................... add fsal_private_op method in export_ops this provide a way to invoke any export function in FSAL layer from ganesha. Change-Id: I5421aca71688fca20ffa8596f11040aeee61a7b0 Signed-off-by: Haihua Yang <yanghh(a)gmail.com> --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_export.c M src/FSAL/default_methods.c M src/include/fsal_api.h 3 files changed, 40 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/29/1225129/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225129?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I5421aca71688fca20ffa8596f11040aeee61a7b0 Gerrit-Change-Number: 1225129 Gerrit-PatchSet: 1 Gerrit-Owner: haihuayang <yanghh(a)gmail.com>

3 weeks, 4 days

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

Devel October 2025