rbd: recreate dummy image with new image features and 1MiB size #2694
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
cc @BenamarMk |
Madhu-1
force-pushed
the
dummy-image-size
branch
from
40a2e6f
to
22d5b40
Compare
ShyamsundarR
reviewed
Dec 7, 2021
BenamarMk
reviewed
Dec 7, 2021
Madhu-1
force-pushed
the
dummy-image-size
branch
from
22d5b40
to
5fd59f2
Compare
BenamarMk
approved these changes
Dec 7, 2021
Madhu-1
force-pushed
the
dummy-image-size
branch
from
5fd59f2
to
777d3ac
Compare
ShyamsundarR
approved these changes
Dec 7, 2021
agarwal-mudit
approved these changes
Dec 7, 2021
nixpanic
approved these changes
Dec 7, 2021
There was a problem hiding this comment.
Looks OK to me. I am very interested to see an issue (linked with all these workaround fixes) that tracks the Ceph fix, so that we can drop the dummy-image workaround after that. The fixes for this workaround are getting more complex and (still) untested in e2e.
3 tasks
updated TODO list to track the PR's for workaround on #2675 |
we added a workaround for rbd scheduling by creating a dummy image in ceph#2656. with the fix we are creating a dummy image of the size of the first actual rbd image which is sent in EnableVolumeReplication request if the actual rbd image size is 1TiB we are creating a dummy image of 1TiB which is not good. even though its a thin provisioned rbd images this is causing issue for the transfer of the snapshot during the mirroring operation. This commit recreates the rbd image with 1MiB size which is the smaller supported size in rbd. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
The dummy image will be created with 1Mib size. during the snapshot transfer operation the 1Mib will be transferred even if the dummy image doesnot contains any data. adding the new image features `fast-diff,layering,obj-map,exclusive-lock`on the dummy image will ensure that only the diff is transferred to the remote cluster. Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
Madhu-1
force-pushed
the
dummy-image-size
branch
from
777d3ac
to
bcd70f0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
we added a workaround for rbd scheduling by creating a dummy image in #2656. with the fix, we are creating a dummy image of the size of the first actual rbd image which is sent in EnableVolumeReplication request if the actual rbd image size is 1Tib we are creating a dummy image of 1TiB which is not good. even though it's a thin-provisioned rbd image this is causing issues for the transfer of the snapshot during the mirroring operation. The current changes include recreating the rbd image with 1Mib size which is the smaller supported size in rbd.
The dummy image will be created with a 1MiB size. during the snapshot transfer operation, the 1MiB will be transferred even if the dummy image does not contain any data. adding the new image features
fast-diff,layering,obj-map,exclusive-lockon the dummy image will ensure that only the diff is transferred to the remote cluster.Signed-off-by: Madhu Rajanna madhupr007@gmail.com