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

[Zeeshan Ali (Khattak)]

On Mon, Jan 30, 2012 at 5:27 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Mon, Jan 30, 2012 at 08:23:36AM -0700, Eric Blake wrote:
>> 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?
>
> Yep, that would be good.

FWIW +1 from my side too.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124