Bug 2190080
| Summary: | [GSS][Ceph] cephfs clone are stuck in Pending state | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Ceph Storage | Reporter: | Xiubo Li <xiubli> |
| Component: | CephFS | Assignee: | Xiubo Li <xiubli> |
| Status: | CLOSED ERRATA | QA Contact: | Hemanth Kumar <hyelloji> |
| Severity: | high | Docs Contact: | lysanche |
| Priority: | unspecified | ||
| Version: | 5.3 | CC: | amk, bniver, ceph-eng-bugs, cephqe-warriors, ebenahar, hyelloji, kjosy, muagarwa, ocs-bugs, rmandyam, sarora, sostapov, tserlin, vereddy, vshankar, xiubli |
| Target Milestone: | --- | Flags: | hyelloji:
needinfo+
hyelloji: needinfo- |
| Target Release: | 5.3z3 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | ceph-16.2.10-166.el8cp | Doc Type: | Bug Fix |
| Doc Text: |
.Users can find the inodes in the metadata pool
Previously, when the MDS crashed and the `openfiletable` could not be flushed, replacing the MDS would not load a few already opened `CInodes` into the MDCache. If the clients withdrew some requests after reconnection, the MDS would return `-ESTALE` after failing to find the inode in all active peers.
With this fix, load and open the inode from the metadata pool if it is not found in the MDS cache. If it is not found in the metadata pool, it returns `-ESTALE` instead of an infinite loop. It successfully finds the inode in most cases.
|
Story Points: | --- |
| Clone Of: | 2179083 | Environment: | |
| Last Closed: | 2023-05-23 00:19:11 UTC | Type: | --- |
| 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: | 2179083 | ||
| Bug Blocks: | 2203283 | ||
|
Description
Xiubo Li
2023-04-27 05:33:44 UTC
Hi All,
As part of Verification we have followed below steps
1. Created a subvolume and filled it with date
2. Created snapshot for the same
3. Created 7 clones in which 3 will be going to pending state and 4 in-progess state. we are waiting for all clones to get created and deleted them and recreating them in for loop
for i in {1..10};do echo $i; for i in {1..7};do echo $i; ceph fs subvolume snapshot clone cephfs subvol_2 snap_1 clone_${i};echo "Creation of clone Done"; done; sh clone_status.sh;for i in {1..7};do echo $i; ceph fs subvolume rm cephfs clone_${i};echo "Deletion of volume done"; done;echo "##########################################"; done
4. In parallel failed mds with ceph mds fail 0 in loop and waited for it to become active and waited for 30 seconds this is done for 100 times in loop
for i in {1..100};do echo $i; ceph mds fail 0; sh test_mds.sh;echo "##########################################"; done
Please find the logs for the same
http://magna002.ceph.redhat.com/ceph-qe-logs/amar/2190080/
Verified on
[root@ceph-amk-upgrade-1-p2wbr0-node7 ~]# ceph versions
{
"mon": {
"ceph version 16.2.10-172.el8cp (00a157ecd158911ece116ae43095de793ed9f389) pacific (stable)": 3
},
"mgr": {
"ceph version 16.2.10-172.el8cp (00a157ecd158911ece116ae43095de793ed9f389) pacific (stable)": 1
},
"osd": {
"ceph version 16.2.10-172.el8cp (00a157ecd158911ece116ae43095de793ed9f389) pacific (stable)": 8
},
"mds": {
"ceph version 16.2.10-172.el8cp (00a157ecd158911ece116ae43095de793ed9f389) pacific (stable)": 3
},
"overall": {
"ceph version 16.2.10-172.el8cp (00a157ecd158911ece116ae43095de793ed9f389) pacific (stable)": 15
}
}
[root@ceph-amk-upgrade-1-p2wbr0-node7 ~]#
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 (Red Hat Ceph Storage 5.3 Bug Fix 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/RHBA-2023:3259 *** Bug 2219761 has been marked as a duplicate of this bug. *** |