And I agree it was probably an oversight by the original storage devs, using powers of 2 instead of 10, since physical hardware doesn't work that way, but its a bit too late to change now. Its just looks a tad generous I guess. On Jul 12, 2014 8:22 PM, "Marcus" <shadow...@gmail.com> wrote:
> I just stuck to the standard as seen in cloudstack already, i.e. creating > a volume via api with custom offering and creating a disk offering both > require a size value specified in gibibytes (at least if I remember > correctly), but the system internally uses bytes everywhere (with power of > 2) and displays bytes via api. > > The shift 30 thing is just a common way to multiply by power of 2. It has > always seemed cleaner to me than 1024*1024*1024 seen elsewhere. Could > probably have a gibToBytes utility somewhere. > On Jul 12, 2014 12:48 AM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> > wrote: > >> 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>*™* >> >
