On 02/23/2012 08:00 PM, Zeeshan Ali (Khattak) wrote: > From: "Zeeshan Ali (Khattak)" <zeeshanak(a)gnome.org&gt; > > --- >  src/storage/storage_driver.c |    2 +- >  1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c > index df0e291..641944d 100644 > --- a/src/storage/storage_driver.c > +++ b/src/storage/storage_driver.c > @@ -1758,7 +1758,7 @@ storageVolumeResize(virStorageVolPtr obj, >          goto out; >      } > > -    if (abs_capacity > vol->allocation + pool->def->available) { > +    if (abs_capacity > vol->capacity + pool->def->available) { I'm not sure this is right.  If you allow for sparse files and over-commitment of capacity, then sparsely resizing to something that has too much capacity but still fits within allocation limits would be a reasonable that should not be rejected.  I think it is more likely that we have several bugs in this area, in being too lax about which values we are actually checking.  In fact, is the only reason we are checking for overflow is to avoid wasting time doing a partial allocation just to learn at the end that we would hit ENOSPACE? Adding to your commit message with the actual scenario you used to trigger the problem, and why your fix is correct, will go a long way in convincing me that this is needed.

>          virStorageReportError(VIR_ERR_INVALID_ARG, Meanwhile, I just noticed this error code is wrong - the argument was syntactically valid, so the real problem is that we are out of space, which fits better as VIR_ERR_OPERATION_FAILED, or possibly a new error message specific to out-of-space errors.