QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
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
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:




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

      parent reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 17:42 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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git