df: Correct BLOCKSIZE with -k #1906

ankushT369 · 2025-11-29T12:04:11Z

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 · 2025-11-29T12:04:20Z

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

ankushT369 · 2025-12-05T15:12:39Z

@bsdimp, @concussious can you review this ?

jlduran

Thank you! I believe this change is compatible with df. I would like to land D54016, and add a few more tests.

Changes that should ideally land before this PR:

Land D54016
Add a -k and -k -P test

jlduran · 2025-12-02T19:19:38Z

bin/df/df.c

 			/*
 			 * POSIX specifically discusses the behavior of
 			 * both -k and -P. It states that the blocksize should
 			 * be set to 1024. Thus, if this occurs, simply break


I think the last sentence Thus, if this occurs, simply break rather than clobbering the old blocksize. should be removed.

jlduran · 2025-12-02T19:22:10Z

bin/df/df.c

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


I think this } needs to be indented using 3 horizontal tabulation characters.

should i make these changes and squash it here?

ok final :

Remove this one : Thus, if this occurs, simply break ather than clobbering the old blocksize.

and this } needs to be indented using 3 horizontal tabulation characters.

ankushT369 · 2025-12-05T16:49:23Z

@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 · 2025-12-05T16:49:37Z

bin/df/df.c

 			 */
-			if (kflag) {
-			    setenv("BLOCKSIZE", "1024", 1);
+            if (kflag) {


These changes in indentation are not needed.

is there anything can I do to fix this back?

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

jlduran · 2025-12-05T16:50:24Z

@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 · 2025-12-05T17:00:30Z

I did this :

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

ankushT369 · 2025-12-05T17:02:59Z

@jlduran is it ok now ?

concussious · 2025-12-05T17:04:34Z

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

ankushT369 · 2025-12-05T17:09:31Z

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

by 1k I mean 1024

concussious · 2025-12-05T17:12:34Z

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

ankushT369 · 2025-12-05T17:22:37Z

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 · 2025-12-05T17:22:55Z

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 · 2025-12-05T17:34:50Z

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

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. Signed-off-by: Ankush Mondal <[email protected]>

jlduran · 2025-12-05T17:42:08Z

@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 · 2025-12-05T18:09:06Z

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

concussious · 2025-12-05T18:12:23Z

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 · 2025-12-05T18:20:53Z

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 · 2025-12-05T18:21:03Z

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 · 2025-12-05T18:39:24Z

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 · 2025-12-06T01:04:39Z

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 · 2025-12-06T01:36:31Z

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

ankushT369 force-pushed the main branch from 0bef7c0 to 843888f Compare November 29, 2025 12:10

jlduran reviewed Dec 5, 2025

View reviewed changes

ankushT369 force-pushed the main branch from 6e739dd to 554be32 Compare December 5, 2025 17:46

df: Correct BLOCKSIZE with -k #1906

Are you sure you want to change the base?

df: Correct BLOCKSIZE with -k #1906

Conversation

ankushT369 commented Nov 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Nov 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ankushT369 commented Dec 5, 2025

Uh oh!

jlduran left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jlduran Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jlduran Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

ankushT369 Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

jlduran Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

ankushT369 Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

ankushT369 commented Dec 5, 2025

Uh oh!

jlduran Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

ankushT369 Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

concussious Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

jlduran commented Dec 5, 2025

Uh oh!

ankushT369 commented Dec 5, 2025

Uh oh!

ankushT369 commented Dec 5, 2025

Uh oh!

concussious commented Dec 5, 2025

Uh oh!

ankushT369 commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

concussious commented Dec 5, 2025

Uh oh!

ankushT369 commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jlduran commented Dec 5, 2025

Uh oh!

ankushT369 commented Dec 5, 2025

Uh oh!

jlduran commented Dec 5, 2025

Uh oh!

concussious commented Dec 5, 2025

Uh oh!

concussious commented Dec 5, 2025

Uh oh!

ankushT369 commented Dec 5, 2025

Uh oh!

ankushT369 commented Dec 5, 2025

Uh oh!

concussious commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

concussious commented Dec 6, 2025

Uh oh!

bsdimp commented Dec 6, 2025

Uh oh!

ankushT369 commented Nov 29, 2025 •

edited

Loading

github-actions bot commented Nov 29, 2025 •

edited

Loading

jlduran left a comment •

edited

Loading

jlduran Dec 2, 2025 •

edited

Loading

ankushT369 commented Dec 5, 2025 •

edited

Loading

ankushT369 commented Dec 5, 2025 •

edited

Loading

concussious commented Dec 5, 2025 •

edited

Loading