Bug 191270 - [patch] df(1): df -h output missing units when size is 1TB
Summary: [patch] df(1): df -h output missing units when size is 1TB
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: Bugmeister
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-22 11:01 UTC by Jack
Modified: 2024-01-10 03:57 UTC (History)
3 users (show)

See Also:


Attachments
i am describing this patch (499 bytes, patch)
2014-06-24 14:47 UTC, bycn82
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jack 2014-06-22 11:01:50 UTC
root@jack:/home/jack # df -h
Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0     2.6T    1000    1.5T    40%    /

The used size is really 1TB but the T is missing from the df -h output.
Comment 1 Jack 2014-06-22 11:02:26 UTC
T should be G, not T
Comment 2 bycn82 2014-06-22 12:45:25 UTC
(In reply to xxjack12xx from comment #1)
> T should be G, not T

Can you please how the result of command `df' as well? According to the implementation of function `prthumanval()', it should not show any result as `1000' or `1000G', when the value is `1000G', it will display `1.0T' instead.

regards,
bycn82
Comment 3 Jack 2014-06-24 00:05:39 UTC
root@jack:/home/jack # df
Filesystem        1K-blocks       Used      Avail Capacity  Mounted on
/dev/mirror/gm0  2834691060 1048475000 1559440776    40%    /

root@jack:/home/jack # df -k
Filesystem       1024-blocks       Used      Avail Capacity  Mounted on
/dev/mirror/gm0   2834691060 1048475000 1559440776    40%    /

root@jack:/home/jack # df -h
Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0     2.6T    1000    1.5T    40%    /

Filesystem        1K-blocks       Used      Avail Capacity iused     ifree %iused  Mounted on
/dev/mirror/gm0  2834691060 1048475000 1559440776    40%  731598 365637040    0%   /

root@jack:/home/jack # df -g
Filesystem       1G-blocks Used Avail Capacity  Mounted on
/dev/mirror/gm0       2703  999  1487    40%    /

root@jack:/home/jack # df -H
Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0     2.9T    1.1T    1.6T    40%    /

root@jack:/home/jack # df -m
Filesystem       1M-blocks    Used   Avail Capacity  Mounted on
/dev/mirror/gm0    2768252 1023901 1522891    40%    /

root@jack:/home/jack # df -P
Filesystem       512-blocks       Used      Avail Capacity  Mounted on
/dev/mirror/gm0  5669382120 2096950000 3118881552    40%    /
Comment 4 Jack 2014-06-24 00:06:25 UTC
Filesystem        1K-blocks       Used      Avail Capacity iused     ifree %iused  Mounted on
/dev/mirror/gm0  2834691060 1048475000 1559440776    40%  731598 365637040    0%   /

was the df -i output
Comment 5 bycn82 2014-06-24 14:47:00 UTC
Created attachment 144102 [details]
i am describing this patch

		/*
		 * Divide the number until it fits the given column.
		 * If there will be an overflow by the rounding below,
		 * divide once more.
		 */
		for (i = 0;
		    (quotient >= max || (quotient == max - 1 &&
		    remainder >= divisordeccut)) && i < maxscale; i++) {
			remainder = quotient % divisor;
			quotient /= divisor;
		}

Here to calculate the quotient, (max=1000, devisor=1024,) so when the quotient happently become 999, then "quotient >= max" is false! so it will stop and print it,
when quotient is 999, after floor the remainder. it will print 1000
Comment 6 bycn82 2014-06-24 15:01:30 UTC
it was there for decades?
Comment 7 Jack 2014-06-24 18:10:44 UTC
Probably since 1TB wasn't a common thing decades ago
Comment 8 bycn82 2014-06-25 00:23:36 UTC
it will happen when the value is about 1M 1G 1TB...
I think not body noticed it before because it is not important,
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2024-01-10 02:29:09 UTC
^Triage: reassign after no action for some time.

To submitter: does this problem still persist all these years later?
Comment 10 Jack 2024-01-10 03:32:07 UTC
I don't know but I guess we can close it.