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

[Eric Blake <eblake@redhat.com>]

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

On 11/12/2014 10:45 AM, Max Reitz wrote:
> 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?
>>
> 
> 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 %.

Yep, definitely annoying.

> 
> 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.

Solved, but not as clean as your current patch that maintains image
consistency throughout and doesn't require a rebuild.  I guess a
tradeoff of clean images vs. code reuse can go either way.

> 
> 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.

Okay.  Just making sure we are considering alternatives when justifying
why we go with a particular solution.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


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