Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-12-22 at 02:36 -0700, Chun Yan Liu wrote:
> > > b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't 
> > > support 
> > > snapshot of snapshot, so out of scope. For qcow2, delete any disk 
> > > snapshot 
> > > won't affect others. 
> >  
> > For either internal or external if you are removing a snapshot from the 
> > middle of a chain which ends in one or more active disks, then surely 
> > the disk backend associated with those domains need to get some sort of 
> > notification, otherwise they would need to be written *very* carefully 
> > in order to be able to cope with disk metadata changing under their 
> > feet. 
> >  
> > Are you saying that the qemu/qcow implementation has indeed been written 
> > with this in mind and can cope with arbitrary other processes modifying 
> > the qcow metadata under their feet? 
> 
> Yes.
> 
> I add qemu-devel Kevin and Stefan in this thread in case my understanding
> has somewhere wrong.
> 
> Kevin & Stefan,
> 
> About the qcow2 snapshot implementation,  in following snapshot chain case,
> if we delete SNAPSHOT A, will it affect domain 1 and domain 2 which uses
> SNAPSHOT B and SNAPSHOT C?
> 
> From my understanding, creating a snapshot will increases refcount of 
> original data,
> deleting a snapshot only descreases the refcount (won't delete data until the 
> refcount
> becomes 0), so I think it won't affect domain 1 and domain 2.
> Is that right?

I'm not worried about the data being deleted (I'm sure qcow2 will get
that right), but rather about the snapshot chain being collapsed and
therefore the metadata (e.g. the tables of which block is in which
backing file, and perhaps the location of the data itself) changing
while a domain is running, e.g.

BASE---SNAPSHOT A---SNAPSHOT B --- domain 1 
                 `--SNAPSHOT C --- domain 2 

becoming 

BASE----------------SNAPSHOT B --- domain 1 
                 `--SNAPSHOT C --- domain 2 

(essentially changing B and C's tables to accommodate the lack of A)

For an internal snapshot I can see that it would be sensible (and easy)
to keep A around as a "ghost", to avoid this case, and the need to
perhaps move data around or duplicate it.

If A were external though an admin might think they could delete the
file...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel