Bug 1249466
| Summary: | [lshw] DISKSPACE key is off by a few megabytes due to rounding/truncation | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Dan Callaghan <dcallagh> |
| Component: | inventory | Assignee: | Dan Callaghan <dcallagh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 21 | CC: | dcallagh, dowang, mjia, rjoost |
| Target Milestone: | 21.1 | Keywords: | Patch, Regression |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-21 03:25:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dan Callaghan
2015-08-03 05:18:29 UTC
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. 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. (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? (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. Beaker 21.1 has been released. |