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

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.