Open akutz opened 7 years ago
Good catch - we should have used MiB and GiB in namin, comments and headers as the conversion is clearly in powers of 2.
Hi @msterin,
I question why the size values are returned as strings. I suggest switching them to 64-bit integers and always returning kiB
much like the VI SDK does (although they also refer to them as kb
when in fact it's kiB
.
We did not plan this as generic modules or functions, but as something we needed for admin CLI. Thus specific formats. It maybe be more generic if changed, but unless there is a bug it's unlikely to get enough priority to get touched.
Setting to rafiki, code isn't broken at this point and hence decide to fix or drop.
I am working with the VMCI client code and noticed the size information for a VMDK, such as its capacity, is being returned as a string, ex:
100 MB
. I need to convert this to numeric values, so I wrote a parser. However, I decided to validate that these were in fact MB since I know the VI SDK and other tools for gathering this information stores size in numeric, 64-bit integers, commonly as Kb.The
convert.py
script that includes unit conversion functions appears to be incorrect in all of its unit declarations. It treats aGB
as1024
MB
. This is incorrect. Mebibytes (MiB) use the power of 2 whereas Megabytes (MB) use the power of 10.I'm confused as to the intent here now, since it seems the sources in this project are using symbols for MB, GB, KB, etc. but using the values derived from MiB, GiB, kiB.
Which is it? As it is I don't trust any of the size information that is derived from inspecting a VMDK via the VMCI client.