Back to bug 2190080

Who When What Removed Added
Red Hat One Jira (issues.redhat.com) 2023-04-27 05:35:00 UTC Link ID Red Hat Issue Tracker RHCEPH-6575
Xiubo Li 2023-04-27 05:35:46 UTC Target Release 6.1z1 5.3z3
Xiubo Li 2023-04-27 05:36:44 UTC Assignee vshankar xiubli
Xiubo Li 2023-04-27 05:45:57 UTC Status NEW ASSIGNED
Venky Shankar 2023-04-27 06:20:19 UTC Status ASSIGNED POST
Hemanth Kumar 2023-04-29 10:10:30 UTC CC hyelloji, tserlin, vereddy
Status POST MODIFIED
Flags needinfo?(hyelloji)
Flags needinfo?(vereddy)
Fixed In Version ceph-16.2.10-166.el8cp
Flags needinfo?(hyelloji) needinfo?(vereddy) needinfo+
Hemanth Kumar 2023-05-02 11:11:44 UTC Flags needinfo?(hyelloji)
Flags needinfo?(hyelloji) needinfo-
errata-xmlrpc 2023-05-02 15:05:11 UTC Status MODIFIED ON_QA
Amarnath 2023-05-09 05:50:43 UTC Flags needinfo?(xiubli)
CC amk
Xiubo Li 2023-05-11 07:45:35 UTC Flags needinfo?(xiubli)
Amarnath 2023-05-15 12:45:22 UTC Status ON_QA VERIFIED
Ranjini M N 2023-05-17 12:05:17 UTC CC rmandyam
Flags needinfo?(xiubli)
Ranjini M N 2023-05-17 12:08:19 UTC Docs Contact lysanche
Xiubo Li 2023-05-18 03:28:05 UTC Doc Text Cause:

There has one case that when the MDS crashes and the openfiletable journal couldn't be flushed and then the replacing MDS is possibly won't load some already opened CInodes into the MDCache.

Consequence:

And if the clients will retry some requests after reconnected, the MDS will return -ESTALE after failing to find the ino in all active peers.

Fix:

Try to load the and open the inode from metadata pool if couldn't find it in all the MDSs' caches. If still couldn't find it from the metadata pool will return -ESTALE instead of inifinetly looping.

Result:

It can successfully find the inode in most cases, if still couldn't will return a -ESTALE errno instead of infinetly looping.
Doc Type If docs needed, set a value Bug Fix
Xiubo Li 2023-05-18 03:28:29 UTC Flags needinfo?(xiubli)
Ranjini M N 2023-05-19 07:10:58 UTC Blocks 2203283
Ranjini M N 2023-05-19 11:49:58 UTC Doc Text Cause:

There has one case that when the MDS crashes and the openfiletable journal couldn't be flushed and then the replacing MDS is possibly won't load some already opened CInodes into the MDCache.

Consequence:

And if the clients will retry some requests after reconnected, the MDS will return -ESTALE after failing to find the ino in all active peers.

Fix:

Try to load the and open the inode from metadata pool if couldn't find it in all the MDSs' caches. If still couldn't find it from the metadata pool will return -ESTALE instead of inifinetly looping.

Result:

It can successfully find the inode in most cases, if still couldn't will return a -ESTALE errno instead of infinetly looping.
.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.
errata-xmlrpc 2023-05-23 00:01:53 UTC Status VERIFIED RELEASE_PENDING
errata-xmlrpc 2023-05-23 00:19:11 UTC Resolution --- ERRATA
Status RELEASE_PENDING CLOSED
Last Closed 2023-05-23 00:19:11 UTC
errata-xmlrpc 2023-05-23 00:19:42 UTC Link ID Red Hat Product Errata RHBA-2023:3259
Patrick Donnelly 2023-07-06 00:41:39 UTC CC kjosy

Back to bug 2190080