Re: [openstack-dev] [Cinder][Manila]share or volume's size unit

2017-04-11 Thread Duncan Thomas
Changing the size to a float creates rounding issues, and means changes to the db, the api definition, and changes to every single client and client library out there, for very little gain. On 10 April 2017 at 04:41, jun zhong wrote: > I agree with you extend might be

Re: [openstack-dev] [Cinder][Manila]share or volume's size unit

2017-04-09 Thread jun zhong
I agree with you extend might be one way to solve the problem. By the way, How about another way that we could import volume size with float value? such as: 2.5G, 3.4G? Did community consider about it in the begin? 2017-04-07 20:16 GMT+08:00 Duncan Thomas : > Cinder

Re: [openstack-dev] [Cinder][Manila]share or volume's size unit

2017-04-07 Thread Duncan Thomas
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

[openstack-dev] [Cinder][Manila]share or volume's size unit

2017-04-07 Thread jun zhong
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