[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] block-commit & dropping privs
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] block-commit & dropping privs |
Date: |
Tue, 7 Apr 2015 11:24:35 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: [Qemu-block] block-commit & dropping privs, (continued)
- Re: [Qemu-block] block-commit & dropping privs, Kevin Wolf, 2015/04/01
- Re: [Qemu-block] block-commit & dropping privs, Michael Tokarev, 2015/04/02
- Re: [Qemu-block] block-commit & dropping privs, Kevin Wolf, 2015/04/02
- Re: [Qemu-block] block-commit & dropping privs, Michael Tokarev, 2015/04/02
- Re: [Qemu-block] block-commit & dropping privs, Eric Blake, 2015/04/02
- Re: [Qemu-block] [Qemu-devel] block-commit & dropping privs, Jeff Cody, 2015/04/03
- Re: [Qemu-block] [Qemu-devel] block-commit & dropping privs, Eric Blake, 2015/04/03
- Re: [Qemu-block] [Qemu-devel] block-commit & dropping privs, Jeff Cody, 2015/04/03
- Re: [Qemu-block] block-commit & dropping privs, Kevin Wolf, 2015/04/02
- Re: [Qemu-block] block-commit & dropping privs, Michael Tokarev, 2015/04/06
- Re: [Qemu-block] block-commit & dropping privs,
Kevin Wolf <=
- Re: [Qemu-block] [Qemu-devel] block-commit & dropping privs, Jeff Cody, 2015/04/02
- Re: [Qemu-block] [Qemu-devel] block-commit & dropping privs, Kevin Wolf, 2015/04/07