libzutil: allow to display powers of 1000 bytes

[jcassette]

Motivation and Context

ZFS displays bytes with K/M/G/T/P/E prefixes. They represent powers of 1024 bytes, i.e. KiB, MiB, GiB, TiB, PiB, EiB.
Some users may want these prefixes to represent powers of 1000 bytes, i.e. KB, MB, GB, TB, PB, EB.

Description

This adds the new unit format and allows to use such display by defining an environment variable.

How Has This Been Tested?

Not tested. If this draft gathers interest then I will add tests.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[mcmilk]

There should also be a testcase for this new formatting.

[tonyhutter]

This PR works when the value is a byte value, but there are other places where we use ZFS_NICENUM_1024 (perhaps incorrectly) that wont be affected. For example, the JSON code uses ZFS_NICENUM_1024 in an bunch of places:

zfs/cmd/zpool/zpool_main.c

Line 9177 in ca0141f

cb->cb_literal, cb->cb_json_as_int, ZFS_NICENUM_1024);

[jcassette]

Hello and thanks for the feedback

@mcmilk :

There should also be a testcase for this new formatting.

Sure. Could you direct me to an existing test case that I could use as a base?

@tonyhutter :

This PR works when the value is a byte value, but there are other places where we use ZFS_NICENUM_1024 (perhaps incorrectly) that wont be affected. For example, the JSON code uses ZFS_NICENUM_1024 in an bunch of places:

Sorry I missed that.
I can see that ZFS_NICENUM_BYTES is used directly there. This PR does not work in that case currently, and I am not sure how to fix that.
If there are places where ZFS_NICENUM_1024 is used to represent bytes, could that be fixed in another PR by using ZFS_NICENUM_BYTES?

zfs/cmd/zpool/zpool_main.c

Lines 9176 to 9177 in ca0141f

	nice_num_str_nvlist(vds, "read_errors", vs->vs_read_errors,
	cb->cb_literal, cb->cb_json_as_int, ZFS_NICENUM_1024);

In this example, it seems weird to express a number of errors in powers of 1024. (I think nobody expects "100K errors" to be 100Ki = 102400 errors). Maybe a new unit like ZFS_NICENUM_1000 should be used instead?

[mcmilk]

There should also be a testcase for this new formatting.

@jcassette - Sorry, there is currently no such test case, I thought I had seen such test. So no - it seems that this is not needed. Sorry for the noise by me.

[tonyhutter]

I suspect we historically went with the ambiguous K/M/G/T prefixes to get a more precision in the zpool iostat|status 5-char columns. That is, you could print "500.4M" rather then "500MB" or "500MiB" (which wouldn't even fit in 5 chars...)

One possible solution could consist of:

1. ZFS_KB_IS_1000 envar - Default to 1000 instead of 1024 for byte values
2. ZFS_USE_IEC_PREFIX envar - Print KB/MB/GB/TB (base 10) or KiB/MiB/GiB/TiB (base 2) instead of K/M/G/T. This might be a pain to implement due to the 5-char columns, but I suspect it would still be doable.
3. Use ZFS_NICENUM_1000 for error counters in JSON output (and anywhere else its needed).

I'm fine with just number 1 being tacked in this PR, but you can try to fix the other ones if you want.

[jumbi77]

In broader context referencing PR #14598

[tonyhutter]

@jumbi77 thanks for the heads-up on that PR. I think we may need to be even more careful about ZFS_KB_IS_1000 since we've only talked about it for displaying numbers, not setting them. For example, this gets a little ambiguous:

export ZFS_KB_IS_1000=1
zfs set recordsize=8K tank

So we may want to rename the envar to something that wouldn't be ambiguous for those cases. Like include the word "display" or "output" in the envar name or something.

[jcassette]

I have addressed the requested changes. Ready for review.

[tonyhutter]

Should this be?

- const char *units[6][7]
+ const char *units[4][7]

[tonyhutter]

Just thinking ahead - can you rename ZFS_NICENUM_1000 to ZFS_NICENUM_BYTES_1000? That way we could potentially add a SI base 1000 prefix for non-byte values, like:

	    [ZFS_NICENUM_1000] = {"", "K", "M", "G", "T", "P", "E"}
	    [ZFS_NICENUM_BYTES_1000] = {"B", "K", "M", "G", "T", "P", "E"}

I can imagine in the future that we make all non-byte values SI powers of 1000 by default. It's kind of silly that we report zpool status error counters in powers of 1024, for example.

[tonyhutter]

What do you think about rewording these lines to make it explicitly clear this is for byte values only?:

When printing byte values, make all prefixes (like KB, MB, GB, TB, PB, EB) 
represent powers of 1000, not 1024.

[snajpa]

is there anyone actually asking for such functionality? with what rationale if I may? "may want to use" is at least for me personally not really enough :)

what good is it going to be if it's hidden behind an envvar nobody knows about? this is an added code, added maintenance burden one might say, but very little benefit? just because someone "may want"? ;)