Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
This project is now read‑only. Starting Monday, February 2, please use https://ibm-ceph.atlassian.net/ for all bug tracking management.

Bug 2227997

Summary: client: issue a cap release immediately if no cap exists
Product: [Red Hat Storage] Red Hat Ceph Storage Reporter: Xiubo Li <xiubli>
Component: CephFSAssignee: Xiubo Li <xiubli>
Status: CLOSED ERRATA QA Contact: Hemanth Kumar <hyelloji>
Severity: high Docs Contact: Ranjini M N <rmandyam>
Priority: unspecified    
Version: 5.3CC: ceph-eng-bugs, cephqe-warriors, gfarnum, kdreyer, mcaldeir, ngangadh, rmandyam, sostapov, tserlin, vshankar
Target Milestone: ---   
Target Release: 5.3z6   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ceph-16.2.10-231.el8cp Doc Type: Bug Fix
Doc Text:
.Client always sends a caps revocation acknowledgment to the MDS daemon Previously, whenever an MDS daemon sent a caps revocation request to a client and during this time, if the client released the caps and removed the inode, then the client would drop the request directly, but the MDS daemon would need to wait for a cap revoking acknowledgment from the client. Due to this, even when there was no need for caps revocation, the MDS Daemon would continue waiting for an acknowledgement from the client, causing a warning in MDS Daemon health status. With this fix, the client always sends a caps revocation acknowledgment to the MDS Daemon, even when there is no inode existing and the MDS Daemon no longer stays stuck.
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-02-08 16:50:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2258797    

Description Xiubo Li 2023-08-01 06:10:41 UTC
In case:

           mds                             client
                                - Releases cap and put Inode
  - Increase cap->seq and sends
    revokes req to the client
  - Receives release req and    - Receives & drops the revoke req
    skip removing the cap and
    then eval the CInode and
    issue or revoke caps again.
                                - Receives & drops the caps update
                                  or revoke req
  - Health warning for client
    isn't responding to
    mclientcaps(revoke)
All the IMPORT/REVOKE/GRANT cap ops will increase the session seq
in MDS side and then the client need to issue a cap release to
unblock MDS to remove the corresponding cap to unblock possible
waiters.

Fixes: https://tracker.ceph.com/issues/57244
Fixes: https://tracker.ceph.com/issues/61148
Signed-off-by: Xiubo Li xiubli

Comment 1 RHEL Program Management 2023-08-01 06:10:52 UTC
Please specify the severity of this bug. Severity is defined here:
https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity.

Comment 18 Scott Ostapovicz 2023-08-23 15:13:20 UTC
Moving back to z5.

Comment 33 errata-xmlrpc 2024-02-08 16:50:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Red Hat Ceph Storage 5.3 Security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2024:0745