Re: [RFC PATCH 28/41] qemuDomainStorageSourcePrivate: Add per-source private blockjob

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

 



On Fri, Jun 19, 2020 at 15:08:14 -0500, Eric Blake wrote:
> On 6/9/20 10:00 AM, Peter Krempa wrote:
> > We'll need to track multiple blockjobs for populating bitmaps per
> > storage source for internal use. Add a variable into the storage source
> > private data for this purpose.
> 
> Hmm. If the domain has two disks as well as two active bitmaps per disk,
> does that really mean we are tracking four independent blockjobs when
> merging in allocation data into all four bitmaps?

No. The idea is to have 1 blockjob per 'format' node.

If you are doing a backup of 2 disks which both have 3 images, you'd as
a worst case scenario get 4 blockjobs. (the bottom-most images already
contain the partial bitmap so they don't need a bitmap populated from
allocation data.

> 
> > 
> > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
> > ---
> >   src/qemu/qemu_domain.c | 1 +
> >   src/qemu/qemu_domain.h | 4 ++++
> >   2 files changed, 5 insertions(+)
> > 
> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> > index 3239ac1a52..0cd9cf8582 100644
> > --- a/src/qemu/qemu_domain.c
> > +++ b/src/qemu/qemu_domain.c
> > @@ -1230,6 +1230,7 @@ qemuDomainStorageSourcePrivateDispose(void *obj)
> >       g_clear_pointer(&priv->secinfo, qemuDomainSecretInfoFree);
> >       g_clear_pointer(&priv->encinfo, qemuDomainSecretInfoFree);
> >       g_clear_pointer(&priv->httpcookie, qemuDomainSecretInfoFree);
> > +    virObjectUnref(priv->blockjob);
> >   }
> 
> Or are you planning on only using one blockjob per disk, and then when it is
> complete, merging that bitmap into multiple other bitmaps?

No. One bitmap per backing chain layer where it's necessary. The above
struct is virStorageSource.

Rest of the blockjobs is tracked per-disk though.

> 
> Should the blockjob-populate command allow multiple destination bitmaps
> grouped into one job?  Or is that just trading reduced libvirt complexity
> for too much QMP complexity?

That doesn't matter that much, at least not from the point of view of
the blockjob. It does matter later where we merge this bitmap into
multiple destinations. Whether it's worth I'm not sure as we need to be
doing the merge anyways, so it's not that much different if we add one
more or one less bitmap.




[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