cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: Resize Volume Question
Date Sun, 13 Jul 2014 02:22:45 GMT
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.tutkowski@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.tutkowski@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.tutkowski@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.Mehta@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message