qemu-devel
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: Re: [Qemu-devel] block-commit & dropping privs
Date: Fri, 03 Apr 2015 13:49:01 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

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)?

> 
> 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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]