--- Begin Message ---
|
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
--- End Message ---
--- Begin Message ---
|
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.
--- End Message ---