Cinder will store the volume as 1G in the database (and quota) even if
the volume is only 500M. It will stay as 500M when it is attached
though. It's a side effect of importing volumes, but that's usually a
pretty uncommon thing to do, so shouldn't affect many people or cause
a huge amount of trouble.

There are also backends that allocate in units greater than 1G, and so
sometimes give you slightly bigger volumes than you asked for. Cinder
doesn't not go out if its way to support this; again the database and
quota will reflect what you asked for, the attached volume will be a
slightly different size.

In your case, extend might be one way to solve the problem, if you
backend supports it. I'm not certain what will happen if you ask
cinder to extend to 1G a volume it already thinks is 1G... if it
doesn't work, please file a bug.

On 7 April 2017 at 09:01, jun zhong <> wrote:
> Hi guys,
> We know the share's size unit is in gigabiyte in manila, and volume's size
> unit is also in gigabiyte in cinder, But there is a question that the size
> is not exactly after we migrate tradition enviroment to OpenStack.
> For example:
> 1.There is original volume(vol_1) with 500MB size in tradition enviroment
> 2.We want to use openstack to manage this volume(vol_1)
> 3.We can only use 1GB volume to manage the original volume(vol_1), because
> the cinder volume size can not support 500MB.
> How to deal with this? Could we set the volume or share's unit to float or
> something else? or add new unit MB? or just extend the original volume size?
> Thanks
> jun
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Duncan Thomas

OpenStack Development Mailing List (not for usage questions)

Reply via email to