Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

From: Alberto Garcia <berto@igalia.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation
Date: Wed, 12 Apr 2017 14:47:23 +0200	[thread overview]
Message-ID: <w51d1chkd2c.fsf@maestria.local.igalia.com> (raw)
In-Reply-To: <20170411144921.GN4516@noname.str.redhat.com>

On Tue 11 Apr 2017 04:49:21 PM CEST, Kevin Wolf 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?
>
> Refcounts are on a cluster granularity, so you have to COW the whole
> cluster at once. If you copied only a subcluster, you'd lose the
> information where to find the other subclusters.

Individual subclusters don't have reference counts, OFLAG_COPIED would
always be at the cluster level, but else I don't see the problem (see
the reply that I just wrote to Eric).

>> > It if it's a real discard you can just discard it (which is what we
>> > do for compat=0.10 images anyway); but zero-writes will then have
>> > to be come real writes, yes.
>> 
>> Perhaps we can give up that bit for subclusters then, that would
>> allow us to double their number. We would still have the zero flag at
>> the cluster level. Opinions on this, anyone?
>
> No, making the backing file contents reappear is really bad, we don't
> want that.

I'm not talking about making the backing file contents reappear, but
about writing zeroes instead of setting the zero flag.

>> >> Then (3) is effectively the same as (2), just that the subcluster
>> >> bitmaps are at the end of the L2 cluster, and not next to each
>> >> entry.
>> >
>> > Exactly. But it's a difference in implementation, as you won't have
>> > to worry about having changed the L2 table layout; maybe that's a
>> > benefit.
>> 
>> I'm not sure if that would simplify or complicate things, but it's
>> worth considering.
>
> Note that 64k between an L2 entry and the corresponding bitmap is
> enough to make an update not atomic any more. They need to be within
> the same sector to get atomicity.

Good point.

Berto