MAAS UI reports storage size in Gibibytes (base 2) but is labeled GB - Gigabytes (base 10).

Bug #1398405 reported by Jason Hobbs
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Critical
Jason Hobbs
1.7
Fix Released
Undecided
Jason Hobbs

Bug Description

My node is reported in the UI's node listing page as having 119 GB of storage. However, the lshw output shows 128035676160 bytes, which is 128.03567616 GB (Gigabytes).

      <lshw:node id="disk" claimed="true" class="disk" handle="SCSI:00:00:00:00">
       <lshw:description>ATA Disk</lshw:description>
       <lshw:product>TOSHIBA THNSNH12</lshw:product>
       <lshw:vendor>Toshiba</lshw:vendor>
       <lshw:physid>0.0.0</lshw:physid>
       <lshw:businfo>scsi@0:0.0.0</lshw:businfo>
       <lshw:logicalname>/dev/sda</lshw:logicalname>
       <lshw:dev>8:0</lshw:dev>
       <lshw:version>HTGA</lshw:version>
       <lshw:serial>24AS108GTOLY</lshw:serial>
       <lshw:size units="bytes">128035676160</lshw:size>
       <lshw:configuration>
        <lshw:setting id="ansiversion" value="5"/>
        <lshw:setting id="sectorsize" value="512"/>
       </lshw:configuration>
      </lshw:node>

Version: 1.7.1+bzr3373-0ubuntu1

Tags: server-hwe

Related branches

description: updated
Revision history for this message
Gavin Panella (allenap) wrote :

tl;dr Use GiB everywhere because GB is the ambiguous term.

<allenap> rvba: I think we might be at the point where enough people are
  aware of GB and GiB that we ought to clarify which one we mean, or
  show both (which would be my preference).
<rvba> allenap: this field is also something users can edit so we need
  to pick one (even if we can show both in the view page).
<rvba> allenap: also, I don't think we want to display both on the
  listing page.
<allenap> rvba: Right, good point. GB is the ambiguous term, so I
  propose GiB everywhere with GB in tooltips or brackets.

Revision history for this message
Jason Hobbs (jason-hobbs) wrote : Re: [Bug 1398405] Re: MAAS UI reports storage size in Gibibytes (base 2) but is labeled GB - Gigabytes (base 10).

I disagree - MAAS should use gigabytes. I don't think many people know what
a GiB or Gibibyte is. Gigabyte is a well defined SI, IEEE etc term these
days and more commonly used. 'parted' uses gigabytes, drive vendors use
gigabytes. If MAAS uses gibibytes, the numbers it reports won't match what
end users expect. They know a system has a 128 GB drive - it's odd for it
to show up as 119 GiB instead.

On Wed, Dec 3, 2014 at 7:47 AM, Gavin Panella <email address hidden>
wrote:

> tl;dr Use GiB everywhere because GB is the ambiguous term.
>
> <allenap> rvba: I think we might be at the point where enough people are
> aware of GB and GiB that we ought to clarify which one we mean, or
> show both (which would be my preference).
> <rvba> allenap: this field is also something users can edit so we need
> to pick one (even if we can show both in the view page).
> <rvba> allenap: also, I don't think we want to display both on the
> listing page.
> <allenap> rvba: Right, good point. GB is the ambiguous term, so I
> propose GiB everywhere with GB in tooltips or brackets.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1398405
>
> Title:
> MAAS UI reports storage size in Gibibytes (base 2) but is labeled GB -
> Gigabytes (base 10).
>
> Status in MAAS:
> New
>
> Bug description:
> My node is reported in the UI's node listing page as having 119 GB of
> storage. However, the lshw output shows 128035676160 bytes, which is
> 128.03567616 GB (Gigabytes).
>
> <lshw:node id="disk" claimed="true" class="disk"
> handle="SCSI:00:00:00:00">
> <lshw:description>ATA Disk</lshw:description>
> <lshw:product>TOSHIBA THNSNH12</lshw:product>
> <lshw:vendor>Toshiba</lshw:vendor>
> <lshw:physid>0.0.0</lshw:physid>
> <lshw:businfo>scsi@0:0.0.0</lshw:businfo>
> <lshw:logicalname>/dev/sda</lshw:logicalname>
> <lshw:dev>8:0</lshw:dev>
> <lshw:version>HTGA</lshw:version>
> <lshw:serial>24AS108GTOLY</lshw:serial>
> <lshw:size units="bytes">128035676160</lshw:size>
> <lshw:configuration>
> <lshw:setting id="ansiversion" value="5"/>
> <lshw:setting id="sectorsize" value="512"/>
> </lshw:configuration>
> </lshw:node>
>
> Version: 1.7.1+bzr3373-0ubuntu1
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1398405/+subscriptions
>

Revision history for this message
Gavin Panella (allenap) wrote :

You make good points, but will GB mean 10^9 bytes, or 2^30? I assume you mean 10^9 because we're talking about disk space, but gigabyte to a computer person is just as or more likely to mean 2^30 bytes. I don't feel strongly and I'm okay with GB, but we should also have a tooltip or a note in brackets showing the GiB figure too and/or an explanation that GB means 10^9. The reason I went for GiB is because, while it's not as well known, it is unambiguous; people who don't know it will look it up, and if they don't look it up then I have no pity :)

Revision history for this message
Jason Hobbs (jason-hobbs) wrote :

I mean 10^9, which is the official standard SI/IEE/NIST definition these days. If it's good enough for disk vendors, MAC OS X, and parted, it's good enough for MAAS! Showing GiB in a tooltip seems fine too.

Changed in maas:
milestone: none → 1.7.1
tags: added: server-hwe
Revision history for this message
Jason Hobbs (jason-hobbs) wrote :

sparkiegeek pointed this out - https://wiki.ubuntu.com/UnitsPolicy. It recommends using base 10/gigabyte as the unit for disk sizes.

Changed in maas:
status: New → Triaged
importance: Undecided → High
importance: High → Critical
Changed in maas:
assignee: nobody → Jason Hobbs (jason-hobbs)
Revision history for this message
Gavin Panella (allenap) wrote :

> sparkiegeek pointed this out - https://wiki.ubuntu.com/UnitsPolicy. It
> recommends using base 10/gigabyte as the unit for disk sizes.

Cool, that's brilliant, and I saw you filed a separate bug about using
base 2 for memory sizes.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.