qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, mreitz@redhat.com, qemu-block@nongnu.org,
	berto@igalia.com
Subject: Re: [Qemu-devel] [PATCH v7 3/6] qcow2: Reduce REFT_OFFSET_MASK
Date: Fri, 29 Jun 2018 10:22:22 -0500	[thread overview]
Message-ID: <41be61a0-9048-c08f-1a9a-1c213f5103ef@redhat.com> (raw)
In-Reply-To: <20180629084444.GC15588@localhost.localdomain>

On 06/29/2018 03:44 AM, Kevin Wolf wrote:
> Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
>> Match our code to the spec change in the previous patch - there's
>> no reason for the refcount table to allow larger offsets than the
>> L1/L2 tables.
> 
> What about internal snapshots? And anyway, because of the metadata
> overhead, the physical image size of a fully allocated image is always
> going to be at least minimally larger than the virtual disk size.
> 
> I'm not necessarily opposed to making the change if there is a good
> reason to make it, but I don't see a real need for it and the
> justification used here and also in the previous patch is incorrect.

The fact that ext4 cannot hold an image this large is already an 
indication that setting this limit on the refcount table is NOT going to 
bite real users.

Yes, you can argue that with lots of metadata, including internal 
snapshots, and on a capable file system (such as tmpfs) that can even 
hold files this large to begin with, then yes, allowing the refcount to 
exceed this limit will allow slightly more metadata to be crammed into a 
single image.  But will it actually help anyone?

Do I need to respin the series to split patch 2 into the obvious changes 
(stuff unrelated to capping refcount size) vs. the controversial stuff 
(refcount cap and this code change)?

> 
> Kevin
> 
>> In practice, no image has more than 64PB of
>> allocated clusters anyways, as anything beyond that can't be
>> expressed via L2 mappings to host offsets.

If you're opposed to an exact 56-bit limit on the grounds that 56-bit 
guest data plus minimal metadata should still be expressable, would it 
be better to cap refcount at 57-bits?

>>
>> Suggested-by: Alberto Garcia <berto@igalia.com>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
>> Reviewed-by: Alberto Garcia <berto@igalia.com>
>>

>> +++ b/block/qcow2.h
>> @@ -439,7 +439,7 @@ typedef enum QCow2MetadataOverlap {
>>   #define L2E_OFFSET_MASK 0x00fffffffffffe00ULL
>>   #define L2E_COMPRESSED_OFFSET_SIZE_MASK 0x3fffffffffffffffULL
>>
>> -#define REFT_OFFSET_MASK 0xfffffffffffffe00ULL
>> +#define REFT_OFFSET_MASK 0x00fffffffffffe00ULL
>>
>>   static inline int64_t start_of_cluster(BDRVQcow2State *s, int64_t offset)
>>   {
>> -- 
>> 2.14.4
>>
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

  reply	other threads:[~2018-06-29 15:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 19:07 [Qemu-devel] [PATCH v7 0/6] minor qcow2 compression improvements Eric Blake
2018-06-28 19:07 ` [Qemu-devel] [PATCH v7 1/6] qcow2: Prefer byte-based calls into bs->file Eric Blake
2018-06-28 19:07 ` [Qemu-devel] [PATCH v7 2/6] qcow2: Document some maximum size constraints Eric Blake
2018-06-28 19:07 ` [Qemu-devel] [PATCH v7 3/6] qcow2: Reduce REFT_OFFSET_MASK Eric Blake
2018-06-29  8:44   ` Kevin Wolf
2018-06-29 15:22     ` Eric Blake [this message]
2018-06-29 15:43       ` Daniel P. Berrangé
2018-06-29 15:43       ` Kevin Wolf
2018-09-14 18:47         ` Eric Blake
2018-06-28 19:07 ` [Qemu-devel] [PATCH v7 4/6] qcow2: Don't allow overflow during cluster allocation Eric Blake
2018-06-28 19:07 ` [Qemu-devel] [PATCH v7 5/6] iotests: Add new test 220 for max compressed cluster offset Eric Blake
2018-06-28 19:07 ` [Qemu-devel] [PATCH v7 6/6] qcow2: Avoid memory over-allocation on compressed images Eric Blake
2018-06-29  9:03   ` Kevin Wolf
2018-06-29 15:16     ` Eric Blake
2018-06-29 15:47       ` Kevin Wolf
2018-06-29 16:48         ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2018-11-13 22:38         ` [Qemu-devel] " Eric Blake

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=41be61a0-9048-c08f-1a9a-1c213f5103ef@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 \
    /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).