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.
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.
http://gerrit.beaker-project.org/4351
Beaker 21.1 has been released.