Back to bug 2091491
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Xiubo Li | 2022-05-30 06:07:18 UTC | Target Release | 6.1 | 5.3 |
| Assignee | vshankar | xiubli | ||
| Red Hat One Jira (issues.redhat.com) | 2022-05-30 06:09:57 UTC | Link ID | Red Hat Issue Tracker RHCEPH-4415 | |
| Xiubo Li | 2022-05-30 06:10:56 UTC | Link ID | Github ceph/ceph/pull/45955 | |
| Xiubo Li | 2022-05-30 06:11:28 UTC | Link ID | Ceph Project Bug Tracker 55240 | |
| Veera Raghava Reddy | 2022-05-31 21:23:31 UTC | CC | vereddy | |
| Severity | unspecified | high | ||
| Xiubo Li | 2022-07-11 07:36:38 UTC | Status | NEW | POST |
| Target Release | 5.3 | 6.1 | ||
| errata-xmlrpc | 2022-08-15 21:13:36 UTC | Status | POST | MODIFIED |
| CC | tserlin | |||
| Target Release | 6.1 | 6.0 | ||
| Fixed In Version | ceph-17.2.3-1.el9cp | |||
| Status | MODIFIED | ON_QA | ||
| Hemanth Kumar | 2022-08-18 05:42:33 UTC | QA Contact | hyelloji | ymane |
| Yogesh Mane | 2022-08-18 06:47:03 UTC | Flags | needinfo?(xiubli) | |
| Xiubo Li | 2022-08-22 03:12:20 UTC | Flags | needinfo?(xiubli) | |
| Yogesh Mane | 2022-08-24 07:52:21 UTC | Status | ON_QA | VERIFIED |
| Eliska | 2022-09-07 06:16:57 UTC | Flags | needinfo?(xiubli) | |
| CC | ekristov | |||
| Xiubo Li | 2022-09-07 08:31:18 UTC | Flags | needinfo?(xiubli) | |
| Doc Text | Cause: With multiple active mds case, client could send a getattr client request to a replica MDS just after it was created. Consequence: For the setattr client request the client will make a path of '#INODE-NUMBER' because the CInode hasn't been linked yet, and the replica MDS will keep retrying until the auth MDS flushes the mdlog and the C_MDS_openc_finish and link_primary_inode are called at most 5 seconds later. Fix: When the replica MDS trying to find the ino from auth MDS and if couldn't find it then manually trigger mdslog flush. Result: No stuck any more. | |||
| Doc Type | If docs needed, set a value | Bug Fix | ||
| Eliska | 2022-09-13 08:53:03 UTC | Blocks | 2126050 | |
| Eliska | 2022-09-21 13:09:44 UTC | Flags | needinfo?(xiubli) | |
| Eliska | 2022-09-22 14:33:57 UTC | Flags | needinfo?(xiubli) | |
| Eliska | 2022-09-23 07:34:22 UTC | Doc Text | Cause: With multiple active mds case, client could send a getattr client request to a replica MDS just after it was created. Consequence: For the setattr client request the client will make a path of '#INODE-NUMBER' because the CInode hasn't been linked yet, and the replica MDS will keep retrying until the auth MDS flushes the mdlog and the C_MDS_openc_finish and link_primary_inode are called at most 5 seconds later. Fix: When the replica MDS trying to find the ino from auth MDS and if couldn't find it then manually trigger mdslog flush. Result: No stuck any more. | .A replica MDS is no longer stuck, if a client sends a getattr client request just after it was created Previously, if a client sent a getattr client request just after the replica MDS was created, the client would make a path of `#INODE-NUMBER` because the CInode was not linked yet. The replica MDS would keep retrying until the auth MDS flushed the `mdlog` and the `C_MDS_openc_finish` and `link_primary_inode` were called 5 seconds later at most. With this fix, the replica MDS trying to find the `handle_find_ino` from auth MDS would manually trigger `mdslog flush`, if it could not find it. |
| Flags | needinfo?(xiubli) | |||
| Docs Contact | ekristov | |||
| Xiubo Li | 2022-10-08 02:36:54 UTC | Flags | needinfo?(xiubli) needinfo?(xiubli) needinfo?(xiubli) | |
| Eliska | 2022-10-11 09:40:14 UTC | Flags | needinfo?(xiubli) | |
| Doc Text | .A replica MDS is no longer stuck, if a client sends a getattr client request just after it was created Previously, if a client sent a getattr client request just after the replica MDS was created, the client would make a path of `#INODE-NUMBER` because the CInode was not linked yet. The replica MDS would keep retrying until the auth MDS flushed the `mdlog` and the `C_MDS_openc_finish` and `link_primary_inode` were called 5 seconds later at most. With this fix, the replica MDS trying to find the `handle_find_ino` from auth MDS would manually trigger `mdslog flush`, if it could not find it. | .A replica MDS is no longer stuck, if a client sends a getattr client request just after it was created Previously, if a client sent a getattr client request just after the replica MDS was created, the client would make a path of `#INODE-NUMBER` because the `CInode` was not linked yet. The replica MDS would keep retrying until the auth MDS flushed the `mdlog` and the `C_MDS_openc_finish` and `link_primary_inode` were called 5 seconds later at most. With this fix, the replica MDS trying to find the `CInode` from auth MDS would manually trigger `mdslog flush`, if it could not find it. |
||
| Eliska | 2022-10-11 09:43:16 UTC | Doc Text | .A replica MDS is no longer stuck, if a client sends a getattr client request just after it was created Previously, if a client sent a getattr client request just after the replica MDS was created, the client would make a path of `#INODE-NUMBER` because the `CInode` was not linked yet. The replica MDS would keep retrying until the auth MDS flushed the `mdlog` and the `C_MDS_openc_finish` and `link_primary_inode` were called 5 seconds later at most. With this fix, the replica MDS trying to find the `CInode` from auth MDS would manually trigger `mdslog flush`, if it could not find it. | .A replica MDS is no longer stuck, if a client sends a getattr client request just after it was created Previously, if a client sent a getattr client request just after the replica MDS was created, the client would make a path of `#INODE-NUMBER` because the `CInode` was not linked yet. The replica MDS would keep retrying until the auth MDS flushed the `mdlog` and the `C_MDS_openc_finish` and `link_primary_inode` were called 5 seconds later at most. With this fix, the replica MDS trying to find the `CInode` from auth MDS would manually trigger `mdslog flush`, if it could not find it. |
| Xiubo Li | 2022-10-11 12:20:39 UTC | Flags | needinfo?(xiubli) | |
| Red Hat Bugzilla | 2022-12-31 16:21:24 UTC | Assignee | xiubli | vshankar |
| Red Hat Bugzilla | 2022-12-31 19:46:56 UTC | QA Contact | ymane | hyelloji |
| Red Hat Bugzilla | 2022-12-31 19:50:33 UTC | QA Contact | hyelloji | |
| Red Hat Bugzilla | 2023-01-01 05:39:36 UTC | CC | tserlin | |
| Red Hat Bugzilla | 2023-01-01 08:48:15 UTC | CC | vereddy | |
| Red Hat Bugzilla | 2023-01-01 08:49:26 UTC | Assignee | vshankar | nobody |
| Alasdair Kergon | 2023-01-04 04:55:29 UTC | QA Contact | ymane | |
| Alasdair Kergon | 2023-01-04 04:55:53 UTC | Assignee | nobody | xiubli |
| Alasdair Kergon | 2023-01-04 06:25:53 UTC | CC | tserlin | |
| Alasdair Kergon | 2023-01-04 06:59:12 UTC | CC | vereddy | |
| Red Hat Bugzilla | 2023-01-09 08:30:48 UTC | CC | ceph-eng-bugs | |
| Alasdair Kergon | 2023-01-09 19:43:36 UTC | CC | ceph-eng-bugs | |
| errata-xmlrpc | 2023-03-20 18:37:49 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2023-03-20 18:56:39 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2023-03-20 18:56:39 UTC | |||
| errata-xmlrpc | 2023-03-20 18:57:06 UTC | Link ID | Red Hat Product Errata RHBA-2023:1360 |
Back to bug 2091491