Bug 1249466 - [lshw] DISKSPACE key is off by a few megabytes due to rounding/truncation
[lshw] DISKSPACE key is off by a few megabytes due to rounding/truncation
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: inventory (Show other bugs)
21
Unspecified Unspecified
unspecified Severity low (vote)
: 21.1
: ---
Assigned To: Dan Callaghan
tools-bugs
: Patch, Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-03 01:18 EDT by Dan Callaghan
Modified: 2015-10-20 23:25 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-20 23:25:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Callaghan 2015-08-03 01:18:29 EDT
The DISKSPACE key-value is total disk size as an integer number of MiB. Disks are often not a whole number of MiB so beaker-system-scan truncates to an integer.

The bug is that the integer truncation is done before summing all disk sizes, so the total can end up off by a handful of MiB compared with the previous (more accurate) number reported by older versions of beaker-system-scan.
Comment 2 Dan Callaghan 2015-08-13 00:51:17 EDT
It has to be truncated to an integer eventually, key-values cannot be floats. The issue here is just that the truncation is being done too early (should be done at the end after summing and divinding into GB) to avoid cumulative rounding errors.
Comment 3 Dan Callaghan 2015-08-13 00:52:03 EDT
Note that this bug is just about the DISKSPACE key which we will (hopefully, one day) get rid of.

The "proper" disks schema stores number of bytes and we display it with suitable/correct units and rounding in all cases already.
Comment 4 matt jia 2015-08-13 00:54:51 EDT
(In reply to Dan Callaghan from comment #2)
> It has to be truncated to an integer eventually, key-values cannot be
> floats. The issue here is just that the truncation is being done too early
> (should be done at the end after summing and divinding into GB) to avoid
> cumulative rounding errors.

Is it possible that the total is greater than the sum of all the truncated disk sizes?
Comment 5 Dan Callaghan 2015-08-17 00:18:51 EDT
(In reply to matt jia from comment #4)
> Is it possible that the total is greater than the sum of all the truncated
> disk sizes?

Yes. For example the system where I saw this (see https://bugzilla.redhat.com/show_bug.cgi?id=541294#c26) has 4 disks of 36420075008 bytes.

Integer divide then sum gives:
>>> 36420075008 / 1024 / 1024 * 4
138928

Sum then integer divide gives:
>>> 4 * 36420075008 / 1024 / 1024
138931

138931 MB is closer to the real total amount of disk space.
Comment 6 Dan Callaghan 2015-08-17 00:23:56 EDT
http://gerrit.beaker-project.org/4351
Comment 9 Dan Callaghan 2015-10-20 23:25:35 EDT
Beaker 21.1 has been released.

Note You need to log in before you can comment on or make changes to this bug.