New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mds: miscellaneous snap fixes #16778
Conversation
35670ee
to
d6d000b
Compare
submodules for project are unmodified |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see comments inline
CInode *in = head_in; | ||
if (follows > 0) { | ||
in = mdcache->pick_inode_snap(head_in, follows); | ||
// intermediate snap inodes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ukernel Thanks for PR
I believe It would be even better if we start comment with capital letter something as:
// Intermediate snap inodes
Also I believe there is no such use of leaving space between //
and Intermediate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you check the code, almost all comments start with space
<< " wrlock lock " << *lock << " on " << *oldin << dendl; | ||
if (!in->client_caps.empty()) { | ||
const set<snapid_t>& snaps = in->find_snaprealm()->get_snaps(); | ||
// clone caps? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ukernel Same as above comments
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Current mds track both head inodes and snap inodes through unsorted map. The unsorted map makes finding snap inode that follows a given snapid difficult. Currnt MDCache::pick_inode_snap() use snap set to guess snap inode's last. The method isn't reliable because snap set may change after creating the snap inode. For example: MDS cows inode[2,head] with snap set[5,6], which results inode[2,6] and inode[7,head]. Later mds wants to find snap inode that follows snapid 2. But the snap set become [5], mds can't find snap inode [2,5]. Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
previous commit 4b95fbe "mds: properly do null snapflush part2" isn't complete. It doesn't properly handle case that snap get deleted before receiving corresponding snapflush. Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
d6d000b
to
0e435e2
Compare
These flags tell mds if there is pending capsnap explictly. Without this explict notification, mds can only conclude if client has pending capsnap. The method mds use is inefficient and error-prone. Fixes: http://tracker.ceph.com/issues/20752 Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
0e435e2
to
ecde54f
Compare
previous commit "mds: track snap inodes through sorted map" makes MDCache::dump_cache return 1 on success. Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
ba166e4
to
f519fca
Compare
* refs/remotes/upstream/pull/16778/head: mds: fix return value of MDCache::dump_cache mds: new cap message flags indicate if there is pending capsnap mds: properly do null snapflush part2 mds: track snap inodes through sorted map mds: properly drop wrlock when finishing snapflush Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
No description provided.