From: Kevin Wolf <kwolf@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: Max Reitz <mreitz@redhat.com>, Eric Blake <eblake@redhat.com>,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-block] [RFC] Proposed qcow2 extension: subcluster allocation
Date: Thu, 13 Apr 2017 11:02:10 +0200 [thread overview]
Message-ID: <20170413090210.GA5095@noname.redhat.com> (raw)
In-Reply-To: <w51y3v4vijw.fsf@maestria.local.igalia.com>
Am 13.04.2017 um 10:05 hat Alberto Garcia geschrieben:
> On Wed 12 Apr 2017 04:10:46 PM CEST, Max Reitz <mreitz@redhat.com> wrote:
> >> 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.
>
> We discussed this yesterday on IRC, but I'm writing the summary here for
> reference:
>
> if you want be able to create internal snapshots quickly without having
> to copy a lot of data, you need to be able to have multiple references
> to one cluster.
>
> Anyway, it seems that this discussion is only relevant if we're trying
> to save as many bits as possible because we want to store everything in
> a 64-bit entry -alternative (1) from my original e-mail-. I agree that
> for that alternative the usefulness of that bit can be put into
> question.
I think you still need it if you don't want to look at the refcount
blocks for every write. When you take an internal snapshot, you just
increase the refcount of the L2 tables at first and keep the contents
the same, including the subcluster information. On the first write to
the cluster, like with normal images you need to copy the whole cluster,
and whether this is the case is determined with the COPIED flag. (The
copy can actually keep unallocated/zeroed subclusters that way, but data
has to be copied for the whole cluster.)
Of course, in all cases the COPIED flag is just an optimisation because
it's always possible to look at the refcount blocks, but I don't think
there is any difference between subclustered and traditional images in
this respect.
Kevin
next prev parent reply other threads:[~2017-04-13 9:02 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
2017-04-13 8:05 ` Alberto Garcia
2017-04-13 9:02 ` Kevin Wolf [this message]
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=20170413090210.GA5095@noname.redhat.com \
--to=kwolf@redhat.com \
--cc=berto@igalia.com \
--cc=eblake@redhat.com \
--cc=mreitz@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 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).