Re: [Qemu-devel] block-commit & dropping privs

[Jeff Cody <jcody@redhat.com>]

On Fri, Apr 03, 2015 at 01:49:01PM -0600, Eric Blake wrote:
> On 04/02/2015 10:28 PM, Jeff Cody wrote:
> 
> >>
> >> Basically, once a commit crosses more than one file, all intermediate
> >> files are useless and might as well be discarded.
> 
> That's if you do a job-complete operation.  But if you do a job-abort
> operation, the chain is left intact.  What we should probably add is a
> way to do a job-abort operation that leaves the active file intact, but
> which also simultaneously rewrites the backing file of the active image
> to point back to the base image and skip over the intermediate files
> that are now broken.
> 
> >>     But you've pointed out
> >> that by rewriting the backing file of C, we CAN make C still be
> >> consistent and tracking the change since the commit:
> >>
> > 
> > Currently, when we do a commit we drop in the chain all the
> > invalidated intermediate images, and the committed image as well
> > (which is what introduced the bdrv_swap craziness):
> > 
> > [base] <--- [snapA] <--- [snapB] <--- [snapC]
> > 
> > Committing snapB down to the base:
> > 
> > [base] <--- [snapC]  
> > 
> > snapB and snapA are discarded.
> 
> Are we actually changing the backing file metadata of snapC when doing
> this?  And if so, can management applications control the text being
> written (so that it is absolute or relative as desired)?
> 

Yes, and yes: in the QMP block-commit command, there is the optional
argument "backing-file".  If provided, that exact string is written
into snapC as the backing filename.  If not provided, then we use the
"filename" member of the BDS for 'base' (e.g. base_bs->filename);


> > 
> > In the active layer commit, the 'base' that is the recipient of data
> > becomes the new active layer, and we drop all the overlays above it.
> > 
> > If we allow emptying images, we need to either A) empty all images
> > that would have otherwise been dropped, or B) empty the current active 
> > layer, and drop the intermediates.
> > 
> > At first blush, have empty intermediates makes no sense.  But if we
> > consider multi-parent chains, as can be introduced with blockdev-add,
> > perhaps it might:
> > 
> >                                                  /-- [snapE]
> >                                                 /
> > [base] <--- [snapA] <--- [snapB] <--- [snapC] <----- [snapD]
> > 
> > 
> > Say, for performance or cleanup reasons, we want to push snapC into
> > base.  This action invalidates neither snapE or snapD, in theory.
> > 
> > However, in current practice, we drop snapC, snapB, and snapA from
> > the chain. Then either snapE or snapD is now orphaned or worse,
> > depending from which "perspective" the block-commit was done.  But
> > if we just empty snapC, then everything automagically works even in
> > multi-parent chains:
> > 
> >                        /-- [snapE]
> >                       /
> > [base] <---  [snapC] <---- [snapD]
> >              (empty)
> > 
> > So I think it makes sense to provide an option even for the non-active
> > layer block commit case to empty the topmost committed overlay, while
> > dropping the other intermediates.
> 
> At any rate, I'm glad I've got you thinking about it.
> 
> -- 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>