-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
librbd: initial set of changes to migration API for instant-restore #37714
Conversation
The partial result should be based upon buffer-extent positions not the original image-extent positions. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
b502669
to
c5742c8
Compare
overlap == ms.overlap && flatten == ms.flatten && | ||
mirroring == ms.mirroring && mirror_image_mode == ms.mirror_image_mode && | ||
state == ms.state && state_description == ms.state_description; | ||
image_id == ms.image_id && source_spec == ms.source_spec && |
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.
nit: just wondering, wouldn't it be more correct to compare the source spec just after comparing the header type?
It wouldn't make any difference in real life though I suppose...
And just wondering, what was the reason to use json for the migration source spec? It seems that "ceph native encoding" could work here too, similarly how it is used e.g. for encoding different journal event types. |
We want someone to be able to define it on the CLI without using a hexeditor, so once we have a JSON/XML format, we might was well just keep it in the single format instead of creating yet another format (that would also need to be extensible to permit new formats, streams, etc). |
We could make the CLI/API convert the user format to a native ceph encoding (Anyway, I suppose we might want to validate somehow the user input before storing it in the image migration header?) And users can't extent a format until it is supported by librbd, so this extension could be added to the native encoding. But I don't have a strong opinion here. Just ignore if you like your way. |
The initial hooks merely abstract the standard RBD parent/child clone relationship. The basic interface, however, is abstract enough to allow third party data formats and streams to be eventually integrated with RBD live-migration. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The migration open source image state machine will handle how to initialize the source ImageCtx depending on the format and protocol utilized for the source image. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
… spec This source-spec will include a JSON-encoded structure describing the source format and protocol for accessing the source image data. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
c5742c8
to
114ad87
Compare
If we had an intermediate binary format, the OSDs (cls_rbd methods) would still need to treat the The journal was all binary encoded for performance/space efficiency reasons which I don't think applies here. I think at the end of it all, JSON can provide the exact same set of forward and backward protection as native encoding w/o all the extra boilerplate code. I would think at best you just a few bytes of space savings here and there since you wouldn't have to encode key names and non-text values can be binary encoded. Just my opinion. |
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.
LGTM
@dillaman There are test failures [1], cli and python, and valgrind reported a memory leak in deep copy [2]. [1] https://pulpito.ceph.com/trociny-2020-10-23_10:42:30-rbd-wip-mgolub-testing-distro-basic-smithi/ |
The legacy migration source format has explicit pool, namespace, and image parameters. This helper method will convert it into the JSON format that will be used for the new-style migration source-spec. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
When using advanced, non-legacy migration sources like a remote Ceph cluster or a flat file, this API will return the JSON-encoded description of the migration source. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
This will help ensure that the source ImageCtx can be made optional when migrating from a read-only, non-native image source. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
With the exception of the 'prepare' command, always attempt to open the destination image first. This will better align with the ability for read-only, non-native images to be used as a source image. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The file stream helper will translate byte-extent IO read requests to ASIO file read requests on the specified backing file. This can be layered with file format helpers to translate image IO extents down to the backing file. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The raw format maps an abstract, fully allocated, raw block device image to the migration source IO API. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
114ad87
to
81ee1cd
Compare
@trociny Thanks. The first two (cli and python) were due to typos during rebases and have been corrected. I'll fix the memory leak tomorrow as a new appended commit. |
Tweak the format interface's 'read' call to just let the existing read request continue passed the migration layer if the native format is in use. Otherwise, the provided AioCompletion would need to be wrapped with another AioCompletion to prevent the original image dispatch spec from getting lost. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Prevent re-using the same AioCompletion between multiple ImageDispatchSpec objects to prevent the possibility of a memory leak. Signed-off-by: Jason Dillaman <dillaman@redhat.com>
abd22c1
to
32767bb
Compare
@dillaman Jenkins failed on assertion inTestLibRBD.FlushEmptyOpsOnExternalSnapshot, but I suspect it is related to my recent changes to the watcher. I am going to investigate this tomorrow (if the cause is not obvious for you). |
Yeah, it's an issue related to the watcher changes. Looks like the |
jenkins test make check |
pushed #37880 for this. |
@dillaman I missed this before merging (the job was still running when I was looking and later I forgot to check its status before merging), but there was one failure [1], though I have no idea if it is related. If I interpret the logs correctly It seems like the qemu got stuck? Just wanted to let you know in case you had not seen this and would be interested. |
The |
Start the process of allowing a JSON-encoded migration source-spec string to be provided. This implies that migration should always attempt to first open the destination image for execute/commit/abort actions. This also includes an initial implementation of a raw, file-based image source IO path handler.