df: Correct BLOCKSIZE with -k

[ankushT369]

This patch resolves inconsistent behavior between the -k option and other related flags, including -P. Previously, using -k resulted in output displayed in 1024-byte blocks, which did not align with the behavior of similar options such as -m and -g, where output is shown in 1M-blocks and 1G-blocks respectively.

The updated implementation ensures that -k now correctly displays sizes in 1K-blocks. In addition, the patch incorporates the POSIX requirement that when both -k -P are specified, the block size must be explicitly forced to 1024-blocks.

Together, these changes make the behavior of -k consistent, predictable, and compliant with the standard.

[BUG: 290710]

[github-actions[bot]]

Thank you for taking the time to contribute to FreeBSD! All issues resolved.

[ankushT369]

@bsdimp, @concussious can you review this ?

[ankushT369]

@jlduran can u review this ?? I think I did 3 horizontal tab indent this part by mistake is it ok ?

if (kflag) {
    setenv("BLOCKSIZE", "1024", 1);

[jlduran]

@jlduran can u review this ?? I think I did 3 horizontal tab indent this part by mistake is it ok ?

if (kflag) {
    setenv("BLOCKSIZE", "1024", 1);

No, those changes should be reverted.

[ankushT369]

I did this :

What I usually do is copy over the original file, open it split-screen and copy it back.

[ankushT369]

@jlduran is it ok now ?

[concussious]

So, this is changing the behavior to match POSIX? By 1k do you mean 1024 or 1000?

[ankushT369]

So, this is changing the behavior to match POSIX? By 1k do you mean 1024 or 1000?

by 1k I mean 1024

[concussious]

Then please use ISO IEC designation, that's KiB, not K.

[ankushT369]

Then please use ISO IEC designation, that's KiB, not K.

but what I found: According to POSIX standards, "1K" or "1k" is used to refer to 1024 bytes (or units), rather than 1000, in the context of disk space measurement utilities like df.

[jlduran]

I guess this is fine by me, if @concussious or @bsdimp have further suggestions, they have the last word. In my opinion, the title of the commit should be changed to indicate that it only changes the title (just the title) of df's output when using the -k flag to match -m and -g flags. Ideally it should be squashed into one commit. Thank you!

[ankushT369]

@jlduran ok I do have to squash into 1 commit ?? can you help me out with the title of commit ?

[jlduran]

@jlduran ok I do have to squash into 1 commit ?? can you help me out with the title of commit ?

I'm terrible at commit titles, something along the lines of:

df: Fix -k flag consistency with other BLOCKSIZE flags

[concussious]

Then please use ISO IEC designation, that's KiB, not K.

but what I found: According to POSIX standards, "1K" or "1k" is used to refer to 1024 bytes (or units), rather than 1000, in the context of disk space measurement utilities like df.

Yes, and we should use 1024. The international standard for referring to 1024 that is called KiB. K or k is ambiguous because macOS and storage manufacturers refer to k as 1000. When scaled to modern infrastructure, measured in PiB, it's a 12.5% difference, hundreds of terabytes.

We use KiB widely in the tree already:

cd src; git grep KiB | wc -l
    593

I even fixed this in our upstream already:

https://github.com/llvm/llvm-project/commit/44a7ecd1d7485be94d3a92021c650175f100d2f7

So, if we're changing the display text, the current proposed change is a regression. 1024 is specific, KiB is specific, but K or k is just not specific.

https://physics.nist.gov/cuu/Units/binary.html

[concussious]

Then please use ISO IEC designation, that's KiB, not K.

but what I found: According to POSIX standards, "1K" or "1k" is used to refer to 1024 bytes (or units), rather than 1000, in the context of disk space measurement utilities like df.

Actually, do you have a link?

[ankushT369]

Then please use ISO IEC designation, that's KiB, not K.

but what I found: According to POSIX standards, "1K" or "1k" is used to refer to 1024 bytes (or units), rather than 1000, in the context of disk space measurement utilities like df.

Yes, and we should use 1024. The international standard for referring to 1024 that is called KiB. K or k is ambiguous because macOS and storage manufacturers refer to k as 1000. When scaled to modern infrastructure, measured in PiB, it's a 12.5% difference, hundreds of terabytes.

We use KiB widely in the tree already:

cd src; git grep KiB | wc -l
    593

I even fixed this in our upstream already:

llvm/llvm-project@44a7ecd

So, if we're changing the display text, the current proposed change is a regression. 1024 is specific, KiB is specific, but K or k is just not specific.

https://physics.nist.gov/cuu/Units/binary.html

i see 'k' is kind of ambiguous

[ankushT369]

Then please use ISO IEC designation, that's KiB, not K.

but what I found: According to POSIX standards, "1K" or "1k" is used to refer to 1024 bytes (or units), rather than 1000, in the context of disk space measurement utilities like df.

Actually, do you have a link?

https://unix.stackexchange.com/questions/179274/what-does-1k-blocks-column-mean-in-the-output-of-df

[concussious]

Then please use ISO IEC designation, that's KiB, not K.

but what I found: According to POSIX standards, "1K" or "1k" is used to refer to 1024 bytes (or units), rather than 1000, in the context of disk space measurement utilities like df.

Actually, do you have a link?

https://unix.stackexchange.com/questions/179274/what-does-1k-blocks-column-mean-in-the-output-of-df

This kind of stuff is very low level, very old, and has a lot of dependencies. When were talking about this, you must go to the actual spec, not stack exchange or Gemini. Here is the spec:

https://pubs.opengroup.org/onlinepubs/9699919799/

It is very specific about output, but does not mention how to refer to it.

Edit: the most recent version: https://pubs.opengroup.org/onlinepubs/9799919799/

[concussious]

I spoke with some of the other committers, and we couldn't get a consensus to change it. Thank you for your submission Ankush!

[bsdimp]

I beg to differ. I'd planned on landing this

[ankushT369]

@bsdimp any updates ??

[concussious]

Eventually I learned this patch would increase consistency with internal and even external implementations, sorry.

~~it's it's well documented in the manual too. Was: Since the patch removes explicit 1024, should we add it to STANDARDS in df.1 to keep the presented specificity with the software?~~