bug#17505: Interface inconsistency, use of intelligent defaults.

[Pádraig Brady]

On 05/17/2014 01:13 AM, Paul Eggert wrote:
> Pádraig Brady wrote:
> 
>> The attached patch changes the output to:
>>
>>    $ dd if=/dev/zero of=/dev/null bs=256M count=2
>>    2+0 records in
>>    2+0 records out
>>    536870912 bytes (512 MiB) copied, 0.152887 s, 3.3 GiB/s
> 
> I recall considering this when I added this kind of diagnostic to GNU dd back 
> in 2004
> and going with powers-of-1000 abbreviations because secondary storage devices 
> are normally
> measured that way.  For this reason, I expect many users will prefer 
> powers-of-1000 here.

This is a fair point as it's common to transfer MB based images in
MiB sized blocks for example.

Though the 512 MiB above is useful as one can immediately see that the
requested amount was transferred.  Also it imparts more info than
537 MB as that is trivially inferred from the previous number.
Also MiB is not ambiguous wrt base, though I suppose MB isn't
too bad either as MB as per standards and dd input notation is base 1000.

> This is particularly true for transfer rates: it's rare to see "GiB/s" in 
> real-world prose.

Fair point. We'll leave that one as is.

> 
> So it'd be unwise to make this change.
> 
> The simplest thing to do is to leave "dd" alone, which is my mild preference.
> Alternatively, we could make the proposed behavior optional, with the default 
> being the current behavior.

> If we do that, though, the behavior shouldn't be affected by the abbreviation 
> chosen for the block size.
> Even if the block size is given in powers-of-1024 (which is common, because 
> block sizes are about internal
> memory units, where powers-of-1024 are typical), the total number of bytes 
> transferred and the transfer rates
> are more commonly interpreted in the external world, where powers-of-1000 are 
> typical.

It's not worth a new option, but if it was to be conditional perhaps it could be
based on the actual amount transferred rather than the block size.
Or from a mathematical viewpoint, output the number that loses the least info.
Essentially:

  if ((count % 1000) && ! (count % 1024))
    options |= human_base_1024

The attached patch now produces:

  $ dd if=/dev/zero of=/dev/null bs=256M count=2
  2+0 records in
  2+0 records out
  536870912 bytes (512 MiB) copied, 0.200283 s, 2.7 GB/s

  $ truncate -s 256MB disk.img
  $ dd if=disk.img of=/dev/null bs=2M
  122+1 records in
  122+1 records out
  256000000 bytes (256 MB) copied, 0.129617 s, 2.0 GB/s

cheers,
Pádraig.

dd-stats-units.patch
Description: Text Data