[PATCH] Change lvextend to round up for stripped volumes

[Iustin Pop <iustin@google.com>]

On Wed, Jul 08, 2009 at 10:50:03AM +0200, Iustin Pop wrote:
> On Tue, Jul 07, 2009 at 11:17:54PM +0100, Alasdair G Kergon wrote:
> > On Wed, Jul 01, 2009 at 10:45:35PM +0200, Iustin Pop wrote:
> > > Currently lvresize, when growing stripped volumes, rounds down if the
> > > extents delta doesn't match exactly the full stripe size. This is
> > > counterintuitive (we're requesting growth by X amount, and instead we
> > > could get less than X, even though the operation succeded), and also
> > > doesn't match the current behaviour in lvcreate (rounds up) and lvextend
> > > for non-stripped volumes (which also rounds up).
> >  
> > The code is shared between lvextend and lvreduce, and accepts relative
> > as well as absolute sizes, so the logic is not simple.
> 
> Ack. Thanks for pointing it out.
> 
> > The intent was for it to be cautious (consider a filesystem present
> > requiring the precise size specified) by rounding up the amount of
> > change when extending and rounding down the amount of change when
> > reducing.
> 
> But the code doesn't do this. It always rounds down for grows of stripped
> volumes, because the code that does adjust this doesn't care about which
> direction (+ or -) we change the size).
> 
> For example, the initial rounding code (for non-stripped) does take into
> account whether lp-> == SIGN_MINUS or not. But the strip rounding code doesn't
> and always choses one direction of rounding.
> 
> I'll look again at the code and send another patch. I was under the wrong
> impression that lp->extents is the final volume size, and not the delta, so
> rounding lp->extents up is always safe.

So I looked at the code some more and it seems that lp->extents is the intended
final size of the logical volume being resized.

Given this, I think that always rounding up lp->extents is safe; it means that
on grow we'll have a bigger LV than requested, and the same on reduce.

Did I got it right?

thanks,
iustin