What you are seeing sounds like a side-effect of deep-flatten support. If you write to an unallocated extent within a cloned image, the associated object extent must be read from the parent image, modified, and written to the clone image. Since the Infernalis release, this process has been tweaked if the cloned image has a snapshot. In that case, the associated object extent is still read from the parent, but instead of being modified and written to the HEAD revision, it is left unmodified and is written to "pre" snapshot history followed by writing the original modification (w/o the parent's object extent data) to the HEAD revision. This change to the IO path was made to support flattening clones and dissociating them from their parents even if the clone had snapshots. Therefore, what you are seeing with export-diff is actually the backing object extent of data from the parent image written to the clone's "pre" snapshot history. If you had two snapshots and your export-diff'ed from the first to second snapshot, you wouldn't see this extra data. To your question about how to prepare image B to make sure it will be exactly the same, the answer is that you don't need to do anything. In your example above, I am assuming you are manually creating an empty Image B and using "import-diff" to populate it. The difference in the export-diff is most likely related to fact that the clone lost its sparseness on any backing object that was written (e.g. instead of a one or more 512 byte diffs within a backing object extent, you will see a single, full-object extent with zeroes where the parent image had no data). On Wed, Nov 23, 2016 at 5:06 AM, Zhongyan Gu <zhongyan.gu@xxxxxxxxx> wrote: > Let me make the issue more clear. > Suppose I cloned image A from a parent image and create snap1 for image A > and then make some change of image A. > If I did the rbd export-diff @snap1. how should I prepare the existing image > B to make sure it will be exactly same with image A@snap1 after import-diff > against this image B. > > Thanks, > Zhongyan > > > On Wed, Nov 23, 2016 at 11:34 AM, Zhongyan Gu <zhongyan.gu@xxxxxxxxx> wrote: >> >> Thanks Jason, very clear explanation. >> However, I found some strange behavior when export-diff on a cloned image, >> not sure it is a bug on calc_snap_set_diff(). >> The test is, >> Image A is cloned from a parent image. then create snap1 for image A. >> The content of export-diff A@snap1 will be changed when update image A. >> Only after image A has no overlap with parent, the content of export-diff >> A@snap1 is stabled, which is almost zero. >> I don't think it is a designed behavior. export-diff A@snap1 should always >> get a stable output no matter image A is cloned or not. >> >> Please correct me if anything wrong. >> >> Thanks, >> Zhongyan >> >> >> >> >> On Tue, Nov 22, 2016 at 10:31 PM, Jason Dillaman <jdillama@xxxxxxxxxx> >> wrote: >>> >>> On Tue, Nov 22, 2016 at 5:31 AM, Zhongyan Gu <zhongyan.gu@xxxxxxxxx> >>> wrote: >>> > So if initial snapshot is NOT specified, then: >>> > rbd export-diff image@snap1 will diff all data to snap1. this cmd >>> > equals to >>> > : >>> > rbd export image@snap1. Is my understand right or not?? >>> >>> >>> While they will both export all data associated w/ image@snap1, the >>> "export" command will generate a raw, non-sparse dump of the full >>> image whereas "export-diff" will export only sections of the image >>> that contain data. The file generated from "export" can be used with >>> the "import" command to create a new image, whereas the file generated >>> from "export-diff" can only be used with "import-diff" against an >>> existing image. >>> >>> -- >>> Jason >> >> > -- Jason _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |