Bug 729866

Summary: df -h should use human_round_to_nearest in human_output_opts for more accurate results
Product: Red Hat Enterprise Linux 6 Reporter: csb sysadmin <admin>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.0CC: meyering, prc
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-16 13:58:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
df -h human_round_to_nearest patch none

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 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
37.01245117187500000000

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

Thanks,
Sabuj Pattanayek

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

coreutils 8.4 to current 8.9 

How reproducible:

always

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.