Subject: bug#9279: closed (Re: bug#9279: df -h should use human_round_to_nearest in human_output_opts for more accurate results)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 11 Aug 2011 15:52:02 +0000

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 [email-masked].

-- 
9279: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9279
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#9279: df -h should use human_round_to_nearest in human_output_opts for more accurate results
From: Jim Meyering <[email-masked]>
To: Sabuj Pattanayek <[email-masked]>
Cc: [email-masked], Paul Eggert <[email-masked]>
Date: Thu, 11 Aug 2011 17:50:08 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

Subject: df -h should use human_round_to_nearest in human_output_opts for more accurate results
From: Sabuj Pattanayek <[email-masked]>
To: [email-masked]
Date: Thu, 11 Aug 2011 00:54:00 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

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