You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2014/07/11 23:07:01 UTC
Resize Volume Question
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>*™*
Re: Resize Volume Question
Posted by Marcus <sh...@gmail.com>.
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" <sh...@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" <mi...@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 <Ni...@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" <mi...@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>*™*
>>
>
Re: Resize Volume Question
Posted by Marcus <sh...@gmail.com>.
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" <mi...@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 <Ni...@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" <mi...@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 <Ni...@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>*™*
>
Re: Resize Volume Question
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <Ni...@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" <mi...@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 <Ni...@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" <mi...@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>*™*
Re: Resize Volume Question
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <Ni...@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" <mi...@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 <Ni...@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" <mi...@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>*™*
Re: Resize Volume Question
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <Ni...@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" <mi...@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 <Ni...@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" <mi...@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>*™*
Re: Resize Volume Question
Posted by Nitin Mehta <Ni...@citrix.com>.
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" <mi...@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 <Ni...@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" <mi...@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>**
Re: Resize Volume Question
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <Ni...@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" <mi...@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>*™*
Re: Resize Volume Question
Posted by Nitin Mehta <Ni...@citrix.com>.
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" <mi...@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>**