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:26:34 GMT
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" <shadowsor@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.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