Thank you Jason. My test shows in the following case, image B will be exactly same: 1. clone image A from parent: #rbd clone 1124-parent@snap1 A
2. create snap for A #rbd snap create A@snap1 3. create empty image B #rbd create B -s 1 4. export-diff A then impor-diff B: #rbd export-diff A@snap1 -|./rbd import-diff - B 5. check A@snap1 equals B@snap1 #rbd export A@snap1 -|md5sum Exporting image: 100% complete...done. 880709d7352b6c9926beb1d829673366 - #rbd export B@snap1 -|md5sum Exporting image: 100% complete...done. 880709d7352b6c9926beb1d829673366 - output shows A@snap1 equals B@snap1 However, in the following case, image B will not be exactly same: 1. clone image A from parent: #rbd clone 1124-parent@snap1 A 2. create snap for A #rbd snap create A@snap1 3. use fio make some change to A 4. create empty image B #rbd create B -s 1 4. export-diff A then impor-diff B: #rbd export-diff A@snap1 -|./rbd import-diff - B 5. check A@snap1 equals B@snap1 #rbd export A@snap1 -|md5sum Exporting image: 100% complete...done. 880709d7352b6c9926beb1d829673366 - #rbd export B@snap1 -|md5sum Exporting image: 100% complete...done. bbf7cf69a84f3978c66f5eb082fb91ec - output shows A@snap1 DOES NOT equal B@snap1 The second case can always be reproduced. What is wrong with the second case? Thanks, Zhongyan On Wed, Nov 23, 2016 at 10:11 PM, Jason Dillaman <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> wrote: > >>> > >>> On Tue, Nov 22, 2016 at 5:31 AM, Zhongyan Gu <[email protected]> > >>> 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 [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
