qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>, Qemu-block <qemu-block@nongnu.org>,
	Kevin Wolf <kwolf@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: qcow2: Zero-initialization of external data files
Date: Thu, 9 Apr 2020 10:46:56 -0500	[thread overview]
Message-ID: <5a8099d6-3885-2bfe-f85a-477c5cc76a45@redhat.com> (raw)
In-Reply-To: <713d39ff-29f6-f9e0-bbbc-c9b26ffd28a0@redhat.com>

On 4/9/20 10:01 AM, Max Reitz wrote:
> On 09.04.20 16:32, Eric Blake wrote:
>> On 4/9/20 9:10 AM, Max Reitz wrote:
>>
>>>>
>>>> What happens when an operation attempts to unmap things?  Do we reject
>>>> all unmap operations when data-file-raw is set (thus leaving a cluster
>>>> marked as allocated at all times, if we can first guarantee that
>>>> preallocation set things up that way)?
>>> No, unmap operations currently work.  qcow2_free_any_clusters() passes
>>> them through to the external data file.
>>>
>>> The problem is that the unmap also zeroes the L2 entry, so if you then
>>> write data to the raw file, it won’t be visible from the qcow2 side of
>>> things.  However, I’m not sure whether we support modifications of a raw
>>> file when it is already “in use” by a qcow2 image, so maybe that’s fine.
>>
>> We don't support concurrent modification. But if the guest is running
>> and unmaps things, then shuts off, then we edit the raw file offline,
>> then we restart the guest, the guest should see the results of those
>> offline edits.
> 
> Should it?  The specification doesn’t say anything about that.
> 
> In fact, I think we have always said we explicitly discourage that
> because this might lead to outdated metadata; even though we usually
> meant “dirty bitmaps” by that.

Hmm.  Kevin, I'd really like your opinion here.  The point of the 
raw-external-data flag is to state that "qemu MUST ensure that whatever 
is done to this image while the guest is running is reflected through to 
the raw file, so that after the guest stops, the raw file alone is still 
viable to see what the guest saw".  But as you say, there's a difference 
between "the raw file will read what the guest saw" and "we can now edit 
the raw file without regards to the qcow2 wrapper but later reuse of the 
qcow2 wrapper won't be corrupted by those edits".

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



  reply	other threads:[~2020-04-09 15:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-17 16:56 qcow2: Zero-initialization of external data files Max Reitz
2020-04-06 22:22 ` Eric Blake
2020-04-09 13:05   ` Max Reitz
2020-04-09 13:42     ` Eric Blake
2020-04-09 13:47       ` Eric Blake
2020-04-09 14:10         ` Max Reitz
2020-04-09 14:32           ` Eric Blake
2020-04-09 15:01             ` Max Reitz
2020-04-09 15:46               ` Eric Blake [this message]
2020-04-09 15:56                 ` Eric Blake
2020-04-14 12:34                   ` Kevin Wolf
2020-04-14 12:28             ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a8099d6-3885-2bfe-f85a-477c5cc76a45@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).