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

osd: start_flush: filter out removed snaps before determining snapc's #4899

Merged
2 commits merged into from Jul 14, 2015

Conversation

Projects
None yet
3 participants
@theanalyst
Member

theanalyst commented Jun 8, 2015

athanatos added some commits May 27, 2015

ReplicatedPG: start_flush: use filtered snapset
Otherwise, we might send our deletes based on deleted snaps.  This is
problematic since we may have trimmed the clones to which those snaps
belong, causing us to send them at an earlier snap than we used before.

The specific situation was

78:[78, 70, 63, 5a, 58, 57]:[64(63), 58(58, 57)]

with 58 already clean.  To flush 64, we send:

delete@58
delete@59
copyfrom@62

Then, snap 63 is trimmed leaving us with a snapset of:

78:[78, 70, 63, 5a, 58, 57]:[58(58, 57)]

since trim_object doesn't filter the head object snapset snaps.  This
isn't really a bug since in general all snapset users must be aware
that there may be trimmed snaps in snapset::snaps.  However, here
it becomes a problem when we go to flush head:

delete@58 -- ignored due to snapc
delete@59 -- ignored due to snapc
copyfrom@78 -- not ignored

The base pool head is at snap seq 62, so it clones that value into
clone 78(78, 70) instead of forgetting it.  What should have happened
is that we should have based our flushes on filtered snapset:

78:[78, 70, 58, 57]:[58(58, 57)]

Causing us to instead send:

delete@58 -- ignored due to snapc
delete@69 -- not ignored, causes no clone to be made
copyfrom@78 -- not ignored, updates head such that a subsequent clone
will leave 70 out of the clone snaps vector.

Fixes: 11787
Signed-off-by: Samuel Just <sjust@redhat.com>
(cherry picked from commit 6051e25)
ReplicatedPG::trim_object: write filtered snapset while we're at it
If we trimmed an object, we might as well remove the obsolete snaps
as well.

Signed-off-by: Samuel Just <sjust@redhat.com>
(cherry picked from commit 90eb776)

@theanalyst theanalyst self-assigned this Jun 8, 2015

@theanalyst theanalyst added this to the hammer milestone Jun 8, 2015

@theanalyst

This comment has been minimized.

Member

theanalyst commented Jul 10, 2015

@athanatos this has passed the first run of integration tests for hammer at http://tracker.ceph.com/issues/11990#rados Do you think it is ready for merge

@athanatos

This comment has been minimized.

Contributor

athanatos commented Jul 14, 2015

This seems fine to me.

ghost pushed a commit that referenced this pull request Jul 14, 2015

Loic Dachary
Merge pull request #4899 from theanalyst/wip-11911-hammer
start_flush: filter out removed snaps before determining snapc's

Reviewed-by: Samuel Just <sjust@redhat.com>

@ghost ghost merged commit d20f513 into ceph:hammer Jul 14, 2015

@ghost ghost changed the title from start_flush: filter out removed snaps before determining snapc's to osd: start_flush: filter out removed snaps before determining snapc's Aug 4, 2015

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment