GNU bug report logs - #9279
df -h should use human_round_to_nearest in human_output_opts for more accurate results

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9279 in the body.
You can then email your comments to 9279 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sabuj Pattanayek <sabujp <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: df -h should use human_round_to_nearest in human_output_opts for more
	accurate results
Date: Thu, 11 Aug 2011 00:54:00 -0500

Hi,

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)

With my suggested patch (below), 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

Here's my suggested patch against the 8.9 release :

--- df.c.old	2011-08-11 00:45:02.697289000 -0500
+++ df.c	2011-08-11 00:45:45.884017000 -0500
@@ -794,7 +794,7 @@
           inode_format = true;
           break;
         case 'h':
-          human_output_opts = human_autoscale | human_SI | human_base_1024;
+          human_output_opts = human_round_to_nearest |
human_autoscale | human_SI | human_base_1024;
           output_block_size = 1;
           break;
         case 'H':

Thanks,
Sabuj Pattanayek

Message #8 received at 9279 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Sabuj Pattanayek <sabujp <at> gmail.com>
Cc: 9279 <at> debbugs.gnu.org
Subject: Re: bug#9279: df -h should use human_round_to_nearest
	in	human_output_opts for more accurate results
Date: Thu, 11 Aug 2011 08:20:11 -0700

tag 9279 notabug
thanks 

Thanks, but df always rounds up.  POSIX requires this for formats it specifies;
see <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/df.html>
and look for "rounded".  for other formats, I thought it better to be
consistent.

Message #13 received at 9279-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Sabuj Pattanayek <sabujp <at> gmail.com>
Cc: 9279-done <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#9279: df -h should use human_round_to_nearest in
	human_output_opts for more accurate results
Date: Thu, 11 Aug 2011 17:50:08 +0200

Paul Eggert wrote:
> Thanks, but df always rounds up.  POSIX requires this for formats it specifies;
> see <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/df.html>
> and look for "rounded".  for other formats, I thought it better to be
> consistent.

Thanks for the patch.
Note that the consistency argument applies not just to df, but also to
du and ls.  All of those tools are documented to round block counts up.

If you feel ambitious, an alternative may be to extend human.c so that
setting the BLOCK_SIZE envvar to say, "human-readable-round-to-nearest",
makes all of those tools do what you propose.  The "Block size" section
of "info coreutils" describes how the BLOCK_SIZE envvar works.

I'm closing this issue.
If you propose to change gnulib's human.c,
please start a new thread with an appropriate subject.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.