Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of mike.tutkowski@solidfire.com
 designates 209.85.219.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACOnxCjqxTGJx8AqacF45p7SQAnQmFV=-nWh+u8ZxutP55eerw@mail.gmail.com>
References: 
 <CACOnxCiz3G7QYakBfgkibf=ttd_=5tztvapvKjvVVb735enDug@mail.gmail.com>
	<CFE5EEC5.415C2%nitin.mehta@citrix.com>
	<CACOnxChwGUzibY1Qc5hBRm3VMeK4dguzRJM02g9eZwMYsRObEw@mail.gmail.com>
	<CACOnxCjqxTGJx8AqacF45p7SQAnQmFV=-nWh+u8ZxutP55eerw@mail.gmail.com>
Date: Sat, 12 Jul 2014 00:48:17 -0600
Message-ID: 
 <CACOnxCiu4f3Vq=XHkELp24gWwfZHfyRjLWB7uXdSZ39Jb=VVOA@mail.gmail.com>
Subject: Re: Resize Volume Question
From: Mike Tutkowski <mike.tutkowski@solidfire.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=047d7b2e420661e19904fdf97130

--047d7b2e420661e19904fdf97130
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 place=
s
>> 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=C2=B9s why you are seeing bo=
th
>>> 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 h=
ow
>>> >volume sizes are referenced. It seems sometimes we use bytes while oth=
er
>>> >times we use GB. I was thinking the units were bytes here, but they ar=
e
>>> >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 =3D cmd.getSize();
>>> >> >
>>> >> >
>>> >> >                if (newSize !=3D null) {
>>> >> >
>>> >> >                    newSize =3D (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=3Dplay>* *
>>> >>
>>> >>
>>> >
>>> >
>>> >--
>>> >*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=3Dplay>* *
>>>
>>>
>>
>>
>> --
>> *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=3Dplay>*=E2=84=A2*
>>
>
>
>
> --
> *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=3Dplay>*=E2=84=A2*
>


--=20
*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=3Dplay>*=E2=84=A2*

--047d7b2e420661e19904fdf97130--