qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Eric Blake <eblake@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 16:10:18 +0200	[thread overview]
Message-ID: <e91aa2c9-5709-ee1c-d8e9-45f12493613e@redhat.com> (raw)
In-Reply-To: <ff515dc1-0ac1-08c6-b636-cd50c09cab7d@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1858 bytes --]

On 09.04.20 15:47, Eric Blake wrote:
> On 4/9/20 8:42 AM, Eric Blake wrote:
> 
>>>> I'd argue that requiring the user to pre-zero the raw data file is
>>>> undesirable; and that we should instead fix our code to not report the
>>>> image as reading all zeroes when creating with data_file_raw=on.
>>>
>>> OK.  I think that could be achieved by just enforcing @preallocation to
>>> be at least “metadata” whenever @data-file-raw is set.  Would that make
>>> sense?
>>
>> Is a preallocation of metadata sufficient to report things correctly?
>> If so, it seems like a reasonable compromise to me.  I was more
>> envisioning a fix elsewhere: if we are reporting block status of what
>> looks like an unallocated cluster, but data-file-raw is set, we change
>> our answer to instead report it as allocated with unknown contents. 
>> But with preallocation, you either force the qcow2 file to list no
>> cluster as unallocated (which matches the fact that the raw image
>> really is fully allocated) while not touching the raw image, or you
>> can go one step further and request full preallocation to wipe the raw
>> image to 0 in the process.
> 
> 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.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-04-09 14:11 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 [this message]
2020-04-09 14:32           ` Eric Blake
2020-04-09 15:01             ` Max Reitz
2020-04-09 15:46               ` Eric Blake
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=e91aa2c9-5709-ee1c-d8e9-45f12493613e@redhat.com \
    --to=mreitz@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@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).