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