Re: [Qemu-devel] [PATCH 18/21] qcow2: Add function for refcount order amendment

[Max Reitz <mreitz@redhat.com>]

On 2014-11-12 at 15:21, Max Reitz wrote:
> On 2014-11-12 at 15:19, Eric Blake wrote:
>> On 11/10/2014 06:45 AM, Max Reitz wrote:
>>> Add a function qcow2_change_refcount_order() which allows changing the
>>> refcount order of a qcow2 image.
>> A thought: didn't you just submit a patch that marked the image as
>> dirty, nuked the on-disk refcount, then rebuilt one using the in-memory
>> refcounts?  Would reusing THAT code be any better than writing this 
>> patch?
>
> Yes, I thought about that, too... The problem is that that patch 
> requires all refcount blocks to fit in memory at the same time (or 
> generally, the qcow2 check function requires that, for now). I'd 
> really like to avoid that, if possible, but maybe it isn't possible 
> after all.
>
> But if you say it like that ("nuke"), I guess I'll give it a try. 
> Maybe it looks funny enough.

Okay, I gave it a try. It does work, but one problem that would require 
larger changes (which would be relatively easy to review, though, I 
guess...) is a refcount overflow during the image check.

What I did was the following: First, check all refcounts against the 
maximum after the amendment. Second, do an image check without repairing 
anything, because we only want to do this on clean images. Third, wipe 
all references to the existing reftable. Fourth, use a function normally 
used by the image check to calculate the refcounts (which results in the 
in-memory refcount table). Fifth, create new refcount structures using 
the rebuild_refcount_structure() function for image repairing.

There are (at least) three problems with this approach. The first is a 
rather cosmetic one: You can't easily give progress reports. There are 
four time-consuming steps here (wiping references to the existing 
reftable is not time-consuming), so this approach can only say when 25 % 
are done, 50 %, 75 % and 100 %.

The second is that if an error occurs during rebuilding the refcount 
structures, it's close to impossible to restore the old ones, because 
the new structures may have been partially written thus overwriting the 
old ones. But having marked the image dirty should suffice to "solve" this.

And the third one is that the initial check (whether the image is 
consistent at all) may throw an error because of refcount overflows. 
This error will tell you to use amend to increase the refcount width. 
Well, too bad. To solve this, we'd have to be able to do the refcount 
consistency check with an arbitrary refcount order (in this case the 
target refcount order), which would require some work on the check 
functions.

I'll just go with the original idea for now.

Max