All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Alberto Garcia <berto@igalia.com>, Eric Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-block] [RFC] Proposed qcow2 extension: subcluster allocation
Date: Wed, 12 Apr 2017 16:10:46 +0200	[thread overview]
Message-ID: <b1a0b5a7-4528-eba8-630e-dd80bc8c26d2@redhat.com> (raw)
In-Reply-To: <w51fuhdkdbg.fsf@maestria.local.igalia.com>

[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

On 12.04.2017 14:41, Alberto Garcia wrote:
> On Tue 11 Apr 2017 04:45:29 PM CEST, Eric Blake wrote:
>>>>>> (We could even get one more bit if we had a subcluster-flag,
>>>>>> because I guess we can always assume subclustered clusters to have
>>>>>> OFLAG_COPIED and be uncompressed. But still, three bits missing.)
>>>>>
>>>>> Why can we always assume OFLAG_COPIED?
>>>>
>>>> Because partially allocated clusters cannot be used with internal
>>>> snapshots, and that is what OFLAG_COPIED is for.
>>>
>>> Why can't they be used?
>>
>> An internal snapshot causes a COW to happen if another write happens
>> anywhere in the cluster. Setting OFLAG_COPIED is a shorthand for
>> whether the COW must happen, but it is always possible (but slower) to
>> refer back to the refcount to learn the same information.  If we have
>> a cluster with missing subclusters, and need to do a COW, we are
>> already reading from the backing file - so we might as well populate
>> the missing subclusters of the original cluster at that time we write
>> the new updated cluster, at which point we no longer need to mark the
>> cluster as using subclusters.
> 
> I still don't see why we can always assume OFLAG_COPIED. Before doing
> the COW one cluster can have references from multiple snapshots,

Yes...

>                                                                  and
> OFLAG_COPIED is equally valid in that context.

In what context? When having subclusters? Why?

>                                                We still need to know if
> we need to perform COW when writing to it, regardless of whether it has
> subclusters or not.

But why would you reference a cluster multiple times if it has
subclusters? Yes, you can do it in theory, but we could just disallow
it, because it doesn't make sense.

As I've said before, there may be uses for clusters to be referenced
multiple times other than internal snapshots; but right now we only use
it for internal snapshots, and I don't think that disallowing multiple
references for subclustered clusters would be horrible for any of the
other use cases.

> Also, when doing a COW for an internal snapshot we definitely have to
> duplicate the whole cluster, but do we really need to read from the
> backing file? Can't we leave the missing subclusters unallocated in the
> copy?
Can't we just disallow !OFLAG_COPIED for subclustered clusters?

To me it seems you implicitly assume we would want to allow
!OFLAG_COPIED, and based on that you argue how we could do so and what
semantics it would bear. However, I fail to see why we would want that
feature at all.

Max


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

  reply	other threads:[~2017-04-12 14:11 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-06 15:01 [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation Alberto Garcia
2017-04-06 16:40 ` Eric Blake
2017-04-07  8:49   ` Alberto Garcia
2017-04-07 12:41   ` Kevin Wolf
2017-04-07 14:24     ` Alberto Garcia
2017-04-21 21:09   ` [Qemu-devel] proposed qcow2 extension: cluster reservations [was: " Eric Blake
2017-04-22 17:56     ` Max Reitz
2017-04-24 11:45       ` Kevin Wolf
2017-04-24 12:46       ` Alberto Garcia
2017-04-07 12:20 ` [Qemu-devel] " Stefan Hajnoczi
2017-04-07 12:24   ` Alberto Garcia
2017-04-07 13:01   ` Kevin Wolf
2017-04-10 15:32     ` Stefan Hajnoczi
2017-04-07 17:10 ` Max Reitz
2017-04-10  8:42   ` Kevin Wolf
2017-04-10 15:03     ` Max Reitz
2017-04-11 12:56   ` Alberto Garcia
2017-04-11 14:04     ` Max Reitz
2017-04-11 14:31       ` Alberto Garcia
2017-04-11 14:45         ` [Qemu-devel] [Qemu-block] " Eric Blake
2017-04-12 12:41           ` Alberto Garcia
2017-04-12 14:10             ` Max Reitz [this message]
2017-04-13  8:05               ` Alberto Garcia
2017-04-13  9:02                 ` Kevin Wolf
2017-04-13  9:05                   ` Alberto Garcia
2017-04-11 14:49         ` [Qemu-devel] " Kevin Wolf
2017-04-11 14:58           ` Eric Blake
2017-04-11 14:59           ` Max Reitz
2017-04-11 15:08             ` Eric Blake
2017-04-11 15:18               ` Max Reitz
2017-04-11 15:29                 ` Kevin Wolf
2017-04-11 15:29                   ` Max Reitz
2017-04-11 15:30                 ` Eric Blake
2017-04-11 15:34                   ` Max Reitz
2017-04-12 12:47           ` Alberto Garcia
2017-04-12 16:54 ` Denis V. Lunev
2017-04-13 11:58   ` Alberto Garcia
2017-04-13 12:44     ` Denis V. Lunev
2017-04-13 13:05       ` Kevin Wolf
2017-04-13 13:09         ` Denis V. Lunev
2017-04-13 13:36           ` Alberto Garcia
2017-04-13 14:06             ` Denis V. Lunev
2017-04-13 13:21       ` Alberto Garcia
2017-04-13 13:30         ` Denis V. Lunev
2017-04-13 13:59           ` Kevin Wolf
2017-04-13 15:04           ` Alberto Garcia
2017-04-13 15:17             ` Denis V. Lunev
2017-04-18 11:52               ` Alberto Garcia
2017-04-18 17:27                 ` Denis V. Lunev
2017-04-13 13:51         ` Kevin Wolf
2017-04-13 14:15           ` Alberto Garcia
2017-04-13 14:27             ` Kevin Wolf
2017-04-13 16:42               ` [Qemu-devel] [Qemu-block] " Roman Kagan
2017-04-13 14:42           ` [Qemu-devel] " Denis V. Lunev
2017-04-12 17:55 ` Denis V. Lunev
2017-04-12 18:20   ` Eric Blake
2017-04-12 19:02     ` Denis V. Lunev
2017-04-13  9:44       ` Kevin Wolf
2017-04-13 10:19         ` Denis V. Lunev
2017-04-14  1:06           ` [Qemu-devel] [Qemu-block] " John Snow
2017-04-14  4:17             ` Denis V. Lunev
2017-04-18 11:22               ` Kevin Wolf
2017-04-18 17:30                 ` Denis V. Lunev
2017-04-14  7:40             ` Roman Kagan

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=b1a0b5a7-4528-eba8-630e-dd80bc8c26d2@redhat.com \
    --to=mreitz@redhat.com \
    --cc=berto@igalia.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.