Skip to content
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

Revert "osd/OSDMap: allow bidirectional swap of pg-upmap-items" #17760

Merged
merged 1 commit into from Sep 19, 2017

Conversation

Projects
None yet
3 participants
@liewegas
Copy link
Member

commented Sep 15, 2017

This reverts commit 09af9b8.

We need to prevent duplicates in the final result. For example, we
can currently take
[1,2,3] and apply [(1,2)] and get [2,2,3]
or
[1,2,3] and apply [(3,2)] and get [1,2,2]

The rest of the system is not prepared to handle duplicates in the
result set like this.

The reverted commit was intended to allow

[1,2,3] and [(1,2),(2,1)] to get [2,1,3]

to reorder primaries. First, this bidirectional swap is hard to implement
in a way that also prevents dups. For example,
[1,2,3] and [(1,4),(2,3),(3,4)] would give [4,3,4]
but would we just drop the last step we'd have [4,3,3] which
is also invalid, etc. Simpler to just not handle bidirectional
swaps. In practice, they are not needed: if you just want to choose
a different primary then use primary_affinity, or pg_upmap
(not pg_upmap_items).

Fixes: http://tracker.ceph.com/issues/21410
Signed-off-by: Sage Weil sage@redhat.com

Revert "osd/OSDMap: allow bidirectional swap of pg-upmap-items"
This reverts commit 09af9b8.

We need to prevent duplicates in the final result.  For example, we
can currently take
 [1,2,3] and apply [(1,2)] and get [2,2,3]
or
 [1,2,3] and apply [(3,2)] and get [1,2,2]

The rest of the system is not prepared to handle duplicates in the
result set like this.

The reverted commit was intended to allow

 [1,2,3] and [(1,2),(2,1)] to get [2,1,3]

to reorder primaries.  First, this bidirectional swap is hard to implement
in a way that also prevents dups.  For example,
 [1,2,3] and [(1,4),(2,3),(3,4)] would give [4,3,4]
but would we just drop the last step we'd have [4,3,3] which
is also invalid, etc.  Simpler to just not handle bidirectional
swaps.  In practice, they are not needed: if you just want to choose
a different primary then use primary_affinity, or pg_upmap
(not pg_upmap_items).

Fixes: http://tracker.ceph.com/issues/21410
Signed-off-by: Sage Weil <sage@redhat.com>

@liewegas liewegas requested a review from xiexingguo Sep 15, 2017

@liewegas

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2017

Sigh... whatever fix we use will need to go upstream in the kernel too, @idryomov!

@xiexingguo
Copy link
Member

left a comment

I am okay with this

@idryomov

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2017

@liewegas ack

@liewegas liewegas merged commit 5a32ef7 into ceph:master Sep 19, 2017

5 checks passed

Docs: build check OK - docs built
Details
Signed-off-by all commits in this PR are signed
Details
Unmodified Submodules submodules for project are unmodified
Details
make check make check succeeded
Details
make check (arm64) make check succeeded
Details

@liewegas liewegas deleted the liewegas:wip-21410-b branch Sep 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.