[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation
Date: Tue, 11 Apr 2017 16:49:21 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 11.04.2017 um 16:31 hat Alberto Garcia geschrieben:
> On Tue 11 Apr 2017 04:04:53 PM CEST, Max Reitz 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.

> >>> If course, if you'd be willing to give up the all-zeroes state for
> >>> subclusters, it would be enough...
> >> 
> >> I still think that it looks like a better idea to allow having more
> >> subclusters, but giving up the all-zeroes state is a valid
> >> alternative. Apart from having to overwrite with zeroes when a
> >> subcluster is discarded, is there anything else that we would miss?
> >
> > 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. If anything, we'd have to use the cluster level zero flag and
do COW (i.e. write explicit zeros) on the first write to a subcluster in
it. I'd rather keep the zero flag for subclusters.

> >>> By the way, if you'd only allow multiple of 1s overhead
> >>> (i.e. multiples of 32 subclusters), I think (3) would be pretty much
> >>> the same as (2) if you just always write the subcluster information
> >>> adjacent to the L2 table. Should be just the same caching-wise and
> >>> performance-wise.
> >> 
> >> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]