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

[Kevin Wolf]

Am 03.04.2015 um 05:59 hat Jeff Cody geschrieben:
> On Thu, Apr 02, 2015 at 01:24:02PM +0200, Kevin Wolf wrote:
> > Am 02.04.2015 um 12:58 hat Michael Tokarev geschrieben:
> > > When performing commit, does qemu mark the areas in the
> > > overlay file as free after writing contents to the backing
> > > file, or will these areas be written again by a subsequent
> > > commit?  Somehow it smells like each next commit writes
> > > more and more data and completes in more and more time.
> > 
> > With qcow2 and qcow, the committed data is discarded with HMP 'commit'.
> > Other image formats keep the copy.
> > 
> > Live commit always keeps the data in the parent image, but it drops that
> > image from the backing file chain, so effectively it is dropped as well
> > (but you need to remove the file manually to reclaim the space).
> > 
> > Jeff, this sounds like we need to make some changes to unify this. That
> > might mean introducing an option that decides whether an image should be
> > dropped from the chain or emptied.
> 
> Yes, I think this would be a good idea.  I can think of scenarios
> where we would want to keep the original overlay around (i.e., we
> still want a snapshot overlay, but just want to consolidate data).
> But I can't think of any reason we would want to keep a stale
> populated overlay file around.

Well, I can think of a reason, I just don't know if it's relevant in
practice. Imagine a remote backing file where the local file serves
mostly as a cache, perhaps with copy-on-read enabled. Dropping all the
local content just to copy it again on the next access wouldn't be very
useful.

> > Once live commit can provide the same
> > as HMP commit, we should change HMP commit to reuse the live commit
> > code.
> > 
> 
> Hmm. My concern here is there may be times we want the behavior that
> HMP commit provides - faster offline active layer commit, rather than
> a mirror-like operation.  I guess if we do want that behavior,
> however, we could always introduce it as an option to block-commit.
> So yes, let's provide an option to remove or empty the committed
> overlays (applies to all overlays, if there are multiple overlays
> being committed in the chain), and then have HMP commit reuse the live
> commit code.

HMP commit should behave similar enough to vm_stop(), start commit block
job, nested event loop until commit completes, vm_start().

Except maybe if there is already a block job running. You wouldn't be
able to commit then until we support multiple block jobs per device.
(And once we do, you probably want to pause all of the block jobs while
committing to retain the original HMP behaviour.)

Kevin