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 hours, 32 minutes
[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>
2 days, 1 hour
[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>
2 days, 3 hours
[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
2 days, 10 hours
[S] Change in ...nfs-ganesha[next]: Fix Coverity issues: CID 583547, 542655, 509140
by Name of user not set (GerritHub)
Vidya.Thumukunta(a)ibm.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225086?usp=email )
Change subject: Fix Coverity issues: CID 583547, 542655, 509140
......................................................................
Fix Coverity issues: CID 583547, 542655, 509140
583547: Added NULL check for calloc return in node_names allocation
542655: Used std::move(input) to avoid unnecessary copy in trimIPv6Prefix()
509140: Used std::move(get_value) in SimpleMap constructor to prevent redundant copy
Change-Id: I7915593cd7ab545eb55bc896a7e04ccd03c16edb
Signed-off-by: VidyaThumukunta <Vidya.Thumukunta(a)ibm.com>
---
M src/monitoring/dynamic_metrics.cc
M src/tools/ganesha-rados-grace.c
2 files changed, 8 insertions(+), 2 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/86/1225086/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225086?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: I7915593cd7ab545eb55bc896a7e04ccd03c16edb
Gerrit-Change-Number: 1225086
Gerrit-PatchSet: 1
Gerrit-Owner: Vidya.Thumukunta(a)ibm.com
3 days, 10 hours
[M] Change in ...nfs-ganesha[next]: Add cluster_nodeid to NFS core configuration (NFS_CORE_PARAM)
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/+/1225081?usp=email )
Change subject: Add cluster_nodeid to NFS core configuration (NFS_CORE_PARAM)
......................................................................
Add cluster_nodeid to NFS core configuration (NFS_CORE_PARAM)
This PR adds a new configuration parameter, cluster_nodeid, to the NFS core configuration (NFS_CORE_PARAM).
The new parameter stores a per-daemon cluster node identifier (string) that can be consumed by
future features (metrics tagging, id-mapping, coordination, etc.). The change is non-breaking:
the default is empty and existing behaviour remains unchanged.
Change-Id: I71d6b57e9aff79b66cf12ef16482dbe58b1809bb
Signed-off-by: Sreedhar Agraharam <sragraha(a)redhat.com>
---
M src/MainNFSD/nfs_main.c
M src/config_parsing/conf_url_rados.c
M src/config_samples/config.txt
M src/doc/man/ganesha-core-config.rst
M src/include/conf_url_rados.h
M src/include/gsh_config.h
M src/support/nfs_read_conf.c
7 files changed, 46 insertions(+), 11 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/81/1225081/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225081?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: I71d6b57e9aff79b66cf12ef16482dbe58b1809bb
Gerrit-Change-Number: 1225081
Gerrit-PatchSet: 1
Gerrit-Owner: sragraha(a)redhat.com
3 days, 12 hours