From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: Alberto Garcia <berto@igalia.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
Max Reitz <mreitz@redhat.com>
Subject: Re: qcow2 preallocation and backing files
Date: Wed, 20 Nov 2019 17:46:26 +0100 [thread overview]
Message-ID: <20191120164626.GF5779@linux.fritz.box> (raw)
In-Reply-To: <5b57fb5b-4480-2b39-9c60-bbd63f13f1cb@virtuozzo.com>
Am 20.11.2019 um 16:58 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 20.11.2019 18:18, Alberto Garcia wrote:
> > On Wed 20 Nov 2019 01:27:53 PM CET, Vladimir Semeeausntsov-Ogievskiy wrote:
> >
> >> 3. Also, the latter way is inconsistent with discard. Discarded
> >> regions returns zeroes, not clusters from backing. I think discard and
> >> truncate should behave in the same safe zero way.
> >
> > But then PREALLOC_MODE_OFF implies that the L2 metadata should be
> > preallocated (all clusters should be QCOW2_CLUSTER_ZERO_PLAIN), at least
> > when there is a backing file.
> >
> > Or maybe we just forbid PREALLOC_MODE_OFF during resize if there is a
> > backing file ?
> >
>
> Kevin proposed a fix that alters PREALLOC_MODE_OFF behavior if there is
> a backing file, to allocate L2 metadata with ZERO clusters..
>
> I don't think that it's the best thing to do, but it's already done,
> it works and seems appropriate for rc3..
>
> I see now, that change PREALLOC_MODE_OFF behavior may break things,
> first of all qemu-img create, which creating UNALLOCATED qcow2 by
> default for years.
And it still does, because the backing file is added only after giving
the qcow2 image the right size.
But you're right, this is more accidental than by design. I wonder if
there are other problematic cases (and whether merging something like
this in -rc3 isn't rather risky).
> Still, I think that it would be safer to always ZERO expanded part of
> qcow2, regardless of backing file..
>
> We may add PREALLOC_MODE_ZERO, and use it in mirror, commit, and some
> other calls to bdrv_truncate, except for qcow2 image creation of
> course.
What do we do with image formats that don't support zero clusters and
therefore can't provide PREALLOC_MODE_ZERO? Will commit just fail for
them?
> Then, to improve this mode handling in qcow2, to not allocate all L2
> tables, we may add "zero" bit to L1 table entry.
This would be an incompatible image format change that needs to be
explicitly enabled by the user. This might limit its usefulness a bit.
Kevin
next prev parent reply other threads:[~2019-11-20 16:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 12:06 qcow2 preallocation and backing files Alberto Garcia
2019-11-20 12:27 ` Vladimir Sementsov-Ogievskiy
2019-11-20 15:18 ` Alberto Garcia
2019-11-20 15:58 ` Vladimir Sementsov-Ogievskiy
2019-11-20 16:35 ` Alberto Garcia
2019-11-20 16:46 ` Kevin Wolf [this message]
2019-11-20 17:49 ` Vladimir Sementsov-Ogievskiy
2019-11-21 8:51 ` Max Reitz
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=20191120164626.GF5779@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=berto@igalia.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/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).