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 >
