Re: [PATCH 15/32] qemublocktest: Replace 'snapshots' bitmap detection test case data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 18, 2020 at 09:58:35 -0500, Eric Blake wrote:
> On 6/15/20 12:10 PM, Peter Krempa wrote:
> > Use test data which conforms to the new semantics which changed in the
> > previous patch.
> 
> Well, a recent patch (the previous patch only touched tests, rather than
> changing semantics)
> 
> > 
> > The test data was created by the same set of commands as originally in
> > commit 0b27b655b1bac480186ce80457113cd5dc34e6a1
> > 
> > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
> > ---
> >   tests/qemublocktestdata/bitmap/snapshots.json | 1382 +++++++----------
> >   tests/qemublocktestdata/bitmap/snapshots.out  |   13 +-
> >   2 files changed, 588 insertions(+), 807 deletions(-)
> 
> > +++ b/tests/qemublocktestdata/bitmap/snapshots.out
> > @@ -1,12 +1,17 @@
> >   libvirt-1-format:
> > -        d: record:0 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> > +        d: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> > +        a: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> > +        b: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> > +        c: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> >     current: record:1 busy:0 persist:1 inconsist:0 gran:65536 dirty:0
> 
> So, where the old paradigm stitched bitmaps across snapshots (no need to add
> a bitmap to a new snapshot layer if it was already inactive in the old
> layer), the new paradigm says that every reachable checkpoint must have an
> active bitmap in the current layer, in addition to whatever bitmaps it had
> in earlier layers.
> 
> Presumably, upcoming patches will tweak libvirt to actually create these
> bitmaps as part of creating an external snapshot, and I also see how you
> could utilize qemu adding block-dirty-bitmap-populate as a convenient way
> for re-creating such bitmaps after the fact (any bitmap that exists in the
> backing chain should basically mirror the allocation of the current layer in
> the chain).

They are actually already being created by 'qemuDomainSnapshotDiskBitmapsPropagate',
and that code is still valid. But I've noticed that the comment needs to
be fixed probably.




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux