Greetings, while working on implementing disk metrics for Solaris, I found the following comment on the Linux implementation ([EMAIL PROTECTED]:1360) which looked suspicious :
/* We report in GB = 1e9 bytes. */ sadly, in Solaris at least (and also in Linux, NetBSD and OpenBSD AFAIK) the implementation of `df -h` uses divisors of 1024 and there 2^30 for "GB" based on the commonly known interpretation of Gigabyte as described in : http://en.wikipedia.org/wiki/Gigabyte and therefore using 1e9 as a divisor instead of 2^30 will result in mismatches and failures against any test case that uses `df -h` to verify and could potentially confuse sysadmins that are getting different values from ganglia and from the tools they are used to run and get those CFOs curious enough to look at ganglia nervous about their last Hitachi bill that doesn't seem to match the value they were told they paid for. by looking at the other implementations for this metrics it might seem there is no standard (except the de-facto value of 1e9 for the divisor that has been copied around together with the find_disk_space function from Linux) and as can be seen by the following table: AIX: returning in MB (as defined by perfstat_disk_total) BSD: returning in GB of 1e9 bytes (includes darwin, FreeBSD and NetBSD) Solaris: returning in GB of 2^30 bytes hpux, irix, osf, windows (through cygwin): Not yet implemented should we be using the same values and metrics on all systems, and if that is the case which one? blocks, 1K blocks, MB, GB or GiB? if that is the case should I change the solaris implementation to use 1e9 as the divisor for consistency or is matching with the value from `df -h` a better standard? and so we should instead change all the other metrics to match? if we agree in a value and interpretation of GB, should we also apply the corresponding interpretation of MB to the memory metrics or to the interpretation of another commonly used system tool (like free for Linux that defines the readings using powers of 2)? Carlo
