From: Max Reitz <mreitz@redhat.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, qemu-block@nongnu.org
Subject: Re: [PATCH for-5.0 v2 0/4] bug fixes extracted from larger qcow2 zero bit work
Date: Thu, 26 Mar 2020 14:32:05 +0100 [thread overview]
Message-ID: <9017607c-7fa7-4f22-a424-e272edaba942@redhat.com> (raw)
In-Reply-To: <20200324174233.1622067-1-eblake@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1522 bytes --]
On 24.03.20 18:42, Eric Blake wrote:
> My proposal [1] to add an autoclear all-zero-content bit to the qcow2
> format has now stalled into 5.1 territory, but several patches in my
> initial proposal are uncontroversial and obvious bug fixes worth
> having in 5.0.
>
> [1] https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg08075.html
>
> Eric Blake (4):
> qcow2: Comment typo fixes
> qcow2: List autoclear bit names in header
> qcow2: Avoid feature name extension on small cluster size
> sheepdog: Consistently set bdrv_has_zero_init_truncate
OK, so my only real gripe was with the question whether we could make
patch 3 decide dynamically when to include or not include the feature
name table. There’s little difference in practice: Right now, we could
probably get away with including it in images with 4k clusters, then it
would automatically switch to 8k clusters minimum (which is the limit
chosen in patch 3 as-is), and at some theoretical point in the far, far
future it would switch 16k clusters minimum.
I don’t think anyone really cares about whether the feature name table
is in images with 4k clusters or not, and I think we still have a couple
of decades before we the table gets too big for images with 8k clusters
(and we probably won’t be using qcow2 then anymore).
So tl;dr: There’s no practical benefit of deciding dynamically, hence
I’m taking this series as-is:
https://git.xanclic.moe/XanClic/qemu/commits/branch/block
Thanks!
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2020-03-26 13:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 17:42 [PATCH for-5.0 v2 0/4] bug fixes extracted from larger qcow2 zero bit work Eric Blake
2020-03-24 17:42 ` [PATCH v2 1/4] qcow2: Comment typo fixes Eric Blake
2020-03-24 17:42 ` [PATCH v2 2/4] qcow2: List autoclear bit names in header Eric Blake
2020-03-24 17:42 ` [PATCH v2 3/4] qcow2: Avoid feature name extension on small cluster size Eric Blake
2020-03-25 12:42 ` Max Reitz
2020-03-25 13:18 ` Eric Blake
2020-03-25 13:52 ` Max Reitz
2020-03-25 14:01 ` Eric Blake
2020-03-24 17:42 ` [PATCH v2 4/4] sheepdog: Consistently set bdrv_has_zero_init_truncate Eric Blake
2020-03-24 19:33 ` John Snow
2020-03-25 14:45 ` [PATCH-for-5.0 " Philippe Mathieu-Daudé
2020-03-26 13:32 ` Max Reitz [this message]
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=9017607c-7fa7-4f22-a424-e272edaba942@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).