The 05/07/11, Eric Blake wrote:
or, to merge all of base.img into snapshot.qcow2 then change
snapshot.qcow2 to no longer have a backing file, before deleting base.img.
As I understand it, either file can be deleted when a snapshot is no
longer needed, but having the flexibility to decide which of the two
files to delete would be useful, and may require knowing how dirty the
snapshot file is in relation to the original file (if it is 95% dirty,
it is faster to just pull in the last few blocks from base into snapshot
before deleting base, whereas if it is only 5% dirty, it is faster to
sync the dirtied blocks from snapshot back to base before deleting
snapshot). And even if you have control over which of the two images to
delete, you may also want to have control over the final filename used
for the merged image (that is, in the 5% dirty case, use the
snapshot->base merge followed by rename(base,snapshot), rather than
wasting time on the base->snapshot merge, to still get the end result
that the final filename is snapshot).
I agree with your analysis. The current behaviour is blocking us from
using qcow2 snapshots while your RFC fix the issues.
But in your last sentence, what do you mean by "to still get the end
result that the final filename is snapshot"? As end result, are you
talking about:
1) the filename (which would mean we could have moving path for disks)
or
2) the content (the snapshot content is in the final file, always in the
path of the base file)
?
--
Nicolas Sebrecht