[libvirt] [PATCH 1/2] resize: add virStorageVolResize() API

[Eric Blake]

On 01/30/2012 07:28 AM, Daniel P. Berrange wrote:
>>>> Why has this changed from 'unsigned long long' to just 'long long'.
>>>
>>> Because of VIR_STORAGE_VOL_RESIZE_DELTA and
>>> VIR_STORAGE_VOL_RESIZE_SHRINK.  That is,
>>>
>>> virStorageVolResize(vol, -10 * 1024 * 1024, DELTA|SHRINK)
>>>
>>> is a valid call to shave off 10 MiB of data.
>>
>> Isn't that rather redundant. Either you need a negative size, or you
>> need a SHRINK flag. If you have a shrink flag, then we don't need a
>> signed int.
> 
> In fact since our existing  virDomainBlockResize API is already
> using unsigned long long, I'd say we should do shrinkage solely
> based off  the SHRINK flag, and *not* require a negative size
> as well

Here's what I was envisioning:

set my size to an absolute of 10M, regardless of whether it was
previously 5M or 15M:

virStorageVolResize(vol, 10*1024*1024, SHRINK)

set my size to an absolute of 10M, but only if it does not shrink:

virStorageVolResize(vol, 10*1024*1024, 0)

set my size to a relative of 10M larger

virStorageVolResize(vol, 10*1024*1024, DELTA)

set my size to a relative of 10M smaller, provided it was at least 10M
to begin with:

virStorageVolResize(vol, -10*1024*1024, DELTA|SHRINK)

You are proposing that the negative sign should be implied by the
combination of DELTA|SHRINK; I guess I can live with that, since the
other three use cases still work as-is, and DELTA|SHRINK is the only
point where a negative value makes sense (and therefore where implying
the negative is okay).

Shall I go ahead and write the patch?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120130/9acd118b/attachment-0001.sig>