Hi Jerry, On Mon, 14 Apr 2025 17:25:59 -0600, Jerry Hoemann wrote: > On Mon, Apr 14, 2025 at 05:23:38PM -0600, Jerry Hoemann wrote: > > On Sun, Apr 13, 2025 at 07:23:47PM +0200, Jean Delvare wrote: > > > HPE OEM type 242 displays the drive capacity using a function > > > initially designed to display memory sizes. While memory sizes are > > > traditionally expressed using power-of-2 units (KiB, MiB, GiB...), > > > the computer storage industry still uses power-of-10 units (kB, MB, > > > GB...) to express a drive's capacity. > > > > > > Implement a new function displaying capacities using power-of-10 > > > units and use it to display the drive capacity. That way, the number > > > displayed will match the expectations and hardware documentation. > > > > > > Signed-off-by: Jean Delvare <[email protected]> > > > --- > > > Jerry, what do you think? > > > > I'll admit to always thinking of KB, MB, GB in terms of their > > power of 2 definitions as that was how I learned them. > > > > Having said that, the current standards calls for KiB, MiB, GiB, etc., > > for the power of 2 definitions and kB, MB, GB., for power of 10 > > definitions. > > > > In general, I'm okay w/ making the change, but think if dmidecode > > is to have two separate decodings, then it probably should use > > KiB, MiB, GiB, etc., units for the memory usage case. > > > Which is of course what your other patch is doing.....
Yes, this is how I noticed the code in dmi_decode_hp()/type 242 and asked myself how the value would be better presented. > > I'll note that fdisk displays disk size w/ GiB/TiB. So, dmidecode would > > not be alone to show disk capacity in power of 2 units. Indeed, and so does cfdisk. But both also show the drive size in bytes, which makes it easier to match it with the drive specifications. Some other tools support both, for example dd or ls (-h vs --si). I double-checked and drive vendors still advertise the capacities with 1 GB = 1,000,000,000 bytes and 1 TB = 1,000 GB. I thought all desktop environments were using binary prefixes to express file sizes now, but after checking, I found this isn't the case. Windows uses power-of-2 but incorrectly displays the unit as MB, GB etc. XFCE's Thunar uses power-of-2 and correctly displays the unit as MiB, GiB etc. Gnome Nautilus uses power-of-10 (and the appropriate units MB, GB etc.) This can be quite confusing for users of multiple environments. I have no hard opinion on whether dmidecode should display the values using power-of-10 or power-of-2 prefixes, as long as it is unambiguous, which units are being used. I have a slight preference for power-of-10 simply because dmidecode is essentially used as an inventory tool, so I think it makes sense for the displayed value to match the storage capacity as it was advertised by the drive vendor. Note that HPE firmware engineers must have made a decision already, as one possible way to store the drive's capacity is as a 32-bit value in "MB" (at offset 0x0F). I assumed that the value was really in MB (1,000,000 bytes), and the values found in the few HPE Gen10 and Gen10+ dumps I have in my collection support that hypothesis. This is presumably no longer an issue for Gen11 and later, as the new 64-bit value expressed in bytes (offset 0x2C) shall be used instead. Also note that we want to have a dedicated function for this anyway, because we want to display storage sizes using the largest possible unit, while for memory sizes we favor accuracy (to a certain degree). > > (note, i wasn't able to build this patch due to to recent u64 change.) Let me bounce the email to you so that you can give it a try. -- Jean Delvare SUSE L3 Support
