Bug #21843
closedmds: preserve order of requests during recovery of multimds cluster
0%
Description
there are several cases that requests get processed in wrong order
1)
touch a/b/f (handled by mds.1, early reply)
mkdir a/.snap/s1 (handle mds.0)
we should delay taking xlock on snaplock
if mds.1 restarts, the replaying the create request may happen after the mksnap request
2)
rm -f a/b/f (handled by mds.1, early reply)
lookup a/b/f (handled by mds.0, lookup is handled by non-auth mds)
we should delay taking rdlock on replica object
if mds.1 restarts, mds.0 may handle the lookup before mds.1 replays the unlink request
3)
rm -f a/b/f (handled by mds.1 early reply)
rmdir a/b (handled by mds.0)
dirfrag a/b/ is subtree. if mds.1 restart, mds.0 may check if a/b is empty before mds.1 replay the unlink request
we should delay take rdlock on scatterlock
Updated by Zheng Yan over 6 years ago
- Status changed from New to Fix Under Review
Updated by Patrick Donnelly over 6 years ago
- Subject changed from preserve order of requests during recovery of multimds cluster to mds: preserve order of requests during recovery of multimds cluster
- Status changed from Fix Under Review to Pending Backport
- Source set to Development
- Backport set to luminous
- Component(FS) MDS added
Updated by Nathan Cutler over 6 years ago
- Copied to Backport #21947: luminous: mds: preserve order of requests during recovery of multimds cluster added
Updated by Nathan Cutler over 6 years ago
- Has duplicate Bug #22374: luminous: mds: SimpleLock::num_rdlock overloaded added
Updated by Patrick Donnelly over 6 years ago
- Status changed from Pending Backport to Resolved