Bug 729866 - df -h should use human_round_to_nearest in human_output_opts for more accurate results
Summary: df -h should use human_round_to_nearest in human_output_opts for more accurat...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: coreutils
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Ondrej Vasik
QA Contact: qe-baseos-daemons
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-11 06:04 UTC by csb sysadmin
Modified: 2011-08-16 13:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-08-16 13:58:37 UTC

Attachments (Terms of Use)
df -h human_round_to_nearest patch (433 bytes, patch)
2011-08-11 06:04 UTC, csb sysadmin
no flags Details | Diff

Description csb sysadmin 2011-08-11 06:04:25 UTC
Created attachment 517736 [details]
df -h human_round_to_nearest patch

Description of problem:

Actually just sent this to bug-coreutils@gnu.org but posting it here as well.

We have a 37TB filesystem that shows up in the output of df -h as 38TB :

Filesystem            Size  Used Avail Use% Mounted on
blue:/sas2fs03/        38T   24T   14T  63% /blue/sas2

df -k shows :

Filesystem           1K-blocks      Used Available Use% Mounted on
blue:/sas2fs03/      39741816832 25020650784 14721166048  63% /blue/sas2

39741816832 is definitely much closer to 37TB than to 38TB :

% echo "39741816832 / (1024^3)" | bc -l

38TB would be :

% echo "38*1024^3" | bc -l
40802189312 (in 1K-blocks) which is >> 39741816832 (difference of 1060372480 KB)

With my suggested patch, I get correct output :

coreutils-8.9/src% ./df -h /blue/sas2
Filesystem            Size  Used Avail Use% Mounted on
blue:/sas2fs03/        37T   23T   14T  63% /blue/sas2

Sabuj Pattanayek

Version-Release number of selected component (if applicable):

coreutils 8.4 to current 8.9 

How reproducible:


Steps to Reproduce:
1. run df -h
Actual results:

Doesn't round properly

Expected results:

Should round properly

Additional info:

Comment 3 Ondrej Vasik 2011-08-11 08:52:45 UTC
Thanks for suggestion and patch - btw. current version is not 8.9, but 8.12 - but this doesn't matter in that case.
Anyway I don't see your email on bug-coreutils mailing list at the moment ... maybe some mailinglist delay...

Comment 4 Ondrej Vasik 2011-08-11 12:17:01 UTC
Ok, now I see the upstream report - https://lists.gnu.org/archive/html/bug-coreutils/2011-08/msg00047.html , will wait for reaction.

Comment 5 Ondrej Vasik 2011-08-16 13:58:37 UTC
Based on the fact that the patch was rejected by upstream (as not consistent with other utilities and POSIX formats standards), closing this bugzilla WONTFIX. If you plan to propose the other way (gnulib change allowing consistency between utilities) to upstream, feel free to reopen this bugzilla once accepted.

Note You need to log in before you can comment on or make changes to this bug.