Bug #4212: mds: open_snap_parents isn't called all the times it needs to be - CephFS - Ceph

Custom queries

Bug queue
Bug triage
CephFS Bug Triage
CephFS task-easy
CephFS: Available Easy Issues
CephFS: Documentation
Crash queue
Crash triage
Feedback
My issues
Need Review
Pending backports
Product Backlog Scrub
Quincy Backports
Release: Quincy: Backports (open)
Release: Reef: Backports (open)
Release: Squid: Backports (open)
Release: Squid: Features
Release: Squid: Open Issues
Release: Tentacle: Features
Release: Tentacle: Open Issues
Zee CephFS Ticket Well

Actions

Copy link

Bug #4212

closed

mds: open_snap_parents isn't called all the times it needs to be

Added by Greg Farnum about 11 years ago. Updated about 6 years ago.

Status:

Closed

Priority:

High

Assignee:

Zheng Yan

Category:

Target version:

Ceph - v13.0.0

% Done:

Source:

Development

Tags:

snapshots,hard

Backport:

Regression:

Severity:

3 - minor

Reviewed:

Affected Versions:

ceph-qa-suite:

Component(FS):

Common/Protocol, MDS

Labels (FS):

Pull request ID:

Crash signature (v1):

Crash signature (v2):

Description

Prompted by a bug report/paper-over patch from Alexandre, I had a talk with Sage about snapshots. It came out that we need to be calling MDCache::open_snap_parents in a lot of places that we aren't — basically, before anybody opens the inode. Apparently this is tricky?

History
Notes
Property changes

Actions

Copy link

Updated by Greg Farnum about 10 years ago

Priority changed from Normal to Low

Snapshots

Actions

Copy link

Updated by Greg Farnum almost 8 years ago

Category changed from 47 to 89
Component(FS) Common/Protocol, MDS added

Actions

Copy link

Updated by Greg Farnum almost 8 years ago

See the email thread at http://www.spinics.net/lists/ceph-devel/msg12818.html

Unfortunately it doesn't include any summary of the verbal conversation about why we need to open_snap_parents(), which is currently part of the reconnect machinery. Part of what it's doing though is making sure that the client has up-to-date SnapRealm info for any inodes it has open, though. So I guess right now, clients can open an inode without opening all of the relevant SnapRealms, and they need to?

Zheng, does this make any sense?

Actions

Copy link

Updated by Greg Farnum almost 8 years ago

I had a misunderstanding about what data a SnapRealm/sr_t has directly.

So, yes, right now we need all past_parents of a SnapRealm open in order to generate the correct SnapContext. We could avoid that by copying the snaps from our parent when we create a new SnapRealm, and I think we want to do so. Further discussion to come as I evaluate snapshot design options.

Actions

Copy link

Updated by Sage Weil over 7 years ago

Having all past_parents open is hard because of dir renames. Say you do

/a/b/c

and snapshot /a/b, then rename /a/b/c -> /d/c. MDS creates snaprealm for c with parent / and past_parent /a/b. Restart MDS. Then cat /d/c/foo.txt. When we open up the c inode we have to go dig up the past_parent, which can take who knows how many requests and how much time (lookup by ino). Meanwhile, it's in the cache and we do'nt have a state for "i know what this is but you can't use it yet bc i don't know how to render a snapc".

Greg's suggested workaround that we kill past_parents entirely and use the osdmap deleted snaps to build correct snapc's sounds like a better solution to me. We also need to fix rados so that deleted snaps aren't part of the osdmap itself but are instead an auxilliary thing you get from the monitor, but I don't think that change should affect our ability to make this change...

Actions

Copy link