From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfPkW-0007II-Iw for qemu-devel@nongnu.org; Tue, 07 Apr 2015 05:24:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfPkV-0002Q5-Fd for qemu-devel@nongnu.org; Tue, 07 Apr 2015 05:24:48 -0400 Date: Tue, 7 Apr 2015 11:24:35 +0200 From: Kevin Wolf Message-ID: <20150407092435.GE4635@noname.str.redhat.com> References: <55158F8B.9090607@redhat.com> <20150330153634.GC4305@noname.redhat.com> <551BB9DA.7030309@msgid.tls.msk.ru> <551BC040.9000806@msgid.tls.msk.ru> <20150401123417.GF3593@noname.str.redhat.com> <551D20EB.8060800@msgid.tls.msk.ru> <20150402112402.GG6541@noname.str.redhat.com> <551D3032.5080307@msgid.tls.msk.ru> <20150402131938.GH6541@noname.str.redhat.com> <5522A857.5050405@msgid.tls.msk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5522A857.5050405@msgid.tls.msk.ru> Subject: Re: [Qemu-devel] block-commit & dropping privs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: jcody@redhat.com, qemu-devel , qemu-block@nongnu.org Am 06.04.2015 um 17:37 hat Michael Tokarev geschrieben: > 02.04.2015 16:19, Kevin Wolf wrote: > > 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). > > Kevin, did you have a chance to fix this prob (for 2.3)? > 2.1 version does the right thing here. I started working on it on Thursday, but as both Good Friday and Easter Monday are public holidays in Germany, it's not ready yet. I hope to get it ready in time for -rc3. 2.1 does the "right" thing because it doesn't support bdrv_make_empty() for qcow2 yet, which is the function that triggers the buggy header rewrite. But without it, your image can't shrink. > >>>> 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. > > Actually it WAS a bug. Initially I tested with 2.1 version, > and there, neither `commit' HMP command nor `qemu-img commit' > command shrinks the overlay image, so each new commit re-writes > both the new data AND the old data, and never shrinks. With > 2.2 version it works as expected, except of the above problem > with rewriting the base file name. I would call it a new feature rather than a bug fix, but yes, that's new in 2.2 (see above). Kevin