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

[Michael Tokarev]

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.

>> 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?

Thanks,

/mjt