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

[Kevin Wolf]

Am 02.04.2015 um 14:04 hat Michael Tokarev geschrieben:
> 02.04.2015 14:24, Kevin Wolf wrote:
> []
> >> But overall, I think qemu-system should not modify backing
> >> file name in this case.
> > 
> > So you would leave the backing file with the data that you just
> > committed down one level in your backing file chain? Wouldn't that
> > defeat the whole purpose of committing?
> 
> Um.  I don't think we understood each other.
> 
> I experimented with the "non-live" HMP commit command.  This
> one effectively empties everything in the overlay file,
> propagating it to the backing file, but keeps the (now
> empty) overlay.  So from the stacking perspective nothing
> has changed.  Yet, together with with propagation, it also
> modifies the overlay file headers and writes a new name
> of the backing file -- the one it currently uses, which,
> in my case, is virtual /dev/fdset/foo.  It should keep
> the original file name in there, such as win.raw, unless
> explicitly asked to write a different name there.
> 
> If the stack chain were to be modified by commit command,
> yes, the new name should be recorded ofcourse, such as
> after rebase.  But since stack chain is not modified,
> filename should not be modified either.

For the record, we discussed this on IRC:

Yes, we did talk past each other because HMP commit isn't supposed to
touch the backing file name at all, so I didn't expect such behaviour,
yet Michael saw it.

The reason is a bug in qcow2_update_header(). Instead of rewriting the
same value as is already in the image, it writes bs->backing_file to the
image. This was always the same as long as you couldn't override the
backing file name on the command line or in blockdev-add, but now it's
obviously wrong.

It would also rewrite the backing file name on other occasions such as
marking the image dirty with lazy_refcounts=on (i.e. on the first
write request).

> >> 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.
> 
> Hm.  It is discarded, but the file isn't shrinked.  With "non-live"
> commit I don't see a reason why it can't be shrinked too?

This would be a bug as well, but Michael double-checked and it does
shrink in fact.

Kevin