From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
Alberto Garcia <berto@igalia.com>,
qemu-block@nongnu.org
Subject: Re: [PATCH v2 3/4] qcow2: Avoid feature name extension on small cluster size
Date: Wed, 25 Mar 2020 09:01:42 -0500 [thread overview]
Message-ID: <ba268a08-12ad-4290-c754-a1e7d39f7748@redhat.com> (raw)
In-Reply-To: <61b5c2d0-fc76-cc70-ab25-bd75cd785d69@redhat.com>
On 3/25/20 8:52 AM, Max Reitz wrote:
>> If we want to write it like that, which size limit
>> do you propose? Or asked differently, how much space should we reserve
>> for other extension headers + backing file name?
>
> Well, that was the “2k/3k/...” list. :)
>
> The backing file name is limited to 1k, so I suppose that plus 1k for a
> potential external data filename, plus 1k for the rest, so 3k in total?
>
> Now that I look into the spec, I see that it actually doesn’t say that
> the backing filename has to be part of the header cluster. But, well.
qemu enforces that the header is one cluster. But you're right, that
does not appear to directly be a limitation mandated by the spec, and we
could relax qemu to allow the header to be several consecutive clusters.
The tricky part, however, is that the backing file name is NOT
described by a header extension, but rather is just whatever bytes occur
after the final header extension. There's no clear indication anywhere
on when to stop reading those bytes, other than by an implicit limit
such as insisting those bytes fall within the first cluster.
Had we been smarter when designing v3, we would have made the backing
file name a header extension (in fact, it would have been possible to
design the additional fields of v3 to look like an unknown header
extension when parsed by a v2 binary) - but hindsight is 20/20.
>
> It also only says that the image header must be part of the first
> cluster, which in my opinion doesn’t necessarily include its extensions.
> So header extensions (and the backing filename) could actually be in
> consecutive clusters. But that of course would be much more difficult
> to implement.
We'd still want a sane limit even for small-cluster images (maybe "no
more than 2M of header information, regardless of cluster size); or
maybe even introduce a NEW header field and/or extension to make it
obvious how many clusters are being used for the purpose of the metadata
header in this particular image (with sane fallbacks for when that
extension is not present). But you're right - it comes with complexity.
This patch as written is safe for 5.0-rc1, but this discussion about
teaching qemu to permit headers larger than 1 cluster is squarely in the
5.1 category, if at all.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2020-03-25 14:02 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 [this message]
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 ` [PATCH for-5.0 v2 0/4] bug fixes extracted from larger qcow2 zero bit work 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=ba268a08-12ad-4290-c754-a1e7d39f7748@redhat.com \
--to=eblake@redhat.com \
--cc=berto@igalia.com \
--cc=kwolf@redhat.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).