I didn't put this in the ticket, but - historically - when one talks about 1 GB in the persistent-storage world, one means 1,000,000,000 bytes (as opposed to memory, where 1 GB means 1,073,741,824 bytes).
Some systems try to clarify this by using, for example, GB versus GiB. On Sat, Jul 12, 2014 at 12:11 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Oh, by the way, that code documentation is still in my sandbox (i.e. not > committed). I am working on updating the resize-volume logic for 4.5. > Hopefully I'll have it checked in sometime next week. > > > On Sat, Jul 12, 2014 at 12:09 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> OK, so, I did a couple things: >> >> 1) I documented the code in the resize-volume area (there were two places >> that I saw) where we bit shift to convert from GB to bytes. >> >> 2) I created: https://issues.apache.org/jira/browse/CLOUDSTACK-7101 >> >> The ticket will probably have to wait until a major release because >> changing the meaning of that parameter is essentially breaking backward >> compatibility. >> >> >> On Fri, Jul 11, 2014 at 8:47 PM, Nitin Mehta <nitin.me...@citrix.com> >> wrote: >> >>> Mike - Would you mind creating a bug for it or better still adding a >>> comment in the code as a //TODO - standardize it if you can't fix it ? >>> I guess currently dev writing new code doesn't have a good reference >>> whether to take it as bytes or in GB. That¹s why you are seeing both >>> varieties. >>> >>> Thanks, >>> -Nitin >>> >>> On 11/07/14 6:33 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> >>> wrote: >>> >>> >Sure, that makes sense - thanks. >>> > >>> >It's too bad we don't really have a standard for our API in terms of how >>> >volume sizes are referenced. It seems sometimes we use bytes while other >>> >times we use GB. I was thinking the units were bytes here, but they are >>> >GB. >>> > >>> > >>> >On Fri, Jul 11, 2014 at 3:55 PM, Nitin Mehta <nitin.me...@citrix.com> >>> >wrote: >>> > >>> >> Probably converting from GB to bytes ? I recall doing that for >>> creating >>> >> volumes from custom disk offering. >>> >> >>> >> On 11/07/14 2:07 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> >>> >> wrote: >>> >> >>> >> >Hi, >>> >> > >>> >> >In the resize-volume command, I see this logic: >>> >> > >>> >> > if (diskOffering.isCustomized() || >>> >> >volume.getVolumeType().equals(Volume.Type.ROOT)) { >>> >> > >>> >> > newSize = cmd.getSize(); >>> >> > >>> >> > >>> >> > if (newSize != null) { >>> >> > >>> >> > newSize = (newSize << 30); >>> >> > >>> >> > } >>> >> > >>> >> > } >>> >> > >>> >> >Any thoughts on why we are shifting bits 30 places to the left? >>> >> > >>> >> >I don't recall us doing this in other places for long values? >>> >> > >>> >> >This is in VolumeApiServiceImpl.resizeVolume. >>> >> > >>> >> >Thanks! >>> >> >-- >>> >> >*Mike Tutkowski* >>> >> >*Senior CloudStack Developer, SolidFire Inc.* >>> >> >e: mike.tutkow...@solidfire.com >>> >> >o: 303.746.7302 >>> >> >Advancing the way the world uses the cloud >>> >> ><http://solidfire.com/solution/overview/?video=play>* * >>> >> >>> >> >>> > >>> > >>> >-- >>> >*Mike Tutkowski* >>> >*Senior CloudStack Developer, SolidFire Inc.* >>> >e: mike.tutkow...@solidfire.com >>> >o: 303.746.7302 >>> >Advancing the way the world uses the cloud >>> ><http://solidfire.com/solution/overview/?video=play>* * >>> >>> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the cloud >> <http://solidfire.com/solution/overview/?video=play>*™* >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*