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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Sabuj Pattanayek <sabujp <at> gmail.com>
Subject: bug#9279: closed (Re: bug#9279: df -h should use human_round_to_nearest
 in human_output_opts for more accurate results)
Date: Thu, 11 Aug 2011 15:52:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#9279: df -h should use human_round_to_nearest in human_output_opts for more accurate results

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 9279 <at> debbugs.gnu.org.

-- 
9279: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9279
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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.

[Message part 3 (message/rfc822, inline)]

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

Previous Next

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