GNU bug report logs - #17505
Interface inconsistency, use of intelligent defaults.

Previous Next

Full log

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

From: Leslie Satenstein <lsatenstein <at> yahoo.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 17505 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults.
Date: Sat, 17 May 2014 11:29:54 -0004

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

What other kinds of bytes are there.  There are 9 bit bytes, with 
parity as a bit, and some old communication stuff with 7 bit bytes. 
There was also the IBM punchcard bytes. 

For the past 60+ years, since paper tape, bytes have been 8 bits, so 
we should assume that is the standard. UTF-8 is a discussion for 
another time. 

There are metric bytes (1000 bytes) which I would refer to as 000's of 
octets, even though disk manufacturers use 000's in their offer of 
terrabytes and not multiples of 1024.

If the abbreviation (K,M,G,P) precedes  'b', as in Kb, kB, KB, and kb, 
these abbreviations should be interpreted as appropriate multiples of 
1024 bytes (2^10).

If you absolutely want to distinguish between 2^10 vs 10^3  use
Ko, kO, KO, or ko to represent the latter (000's).  

You could apply the above rule to megabytes,  512Mb vs 512Mo
and of course to Gb vs Go, Tb vs To and Pb vs Po (Peta bytes vs Peta 
octets)

All you require is one statement, all multiples of kb are multiples of 
1024 bytes. 


On Sat, May 17, 2014 at 6:32 AM, Pádraig Brady <P <at> draigBrady.com> 
wrote:
> 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.

[Message part 2 (text/html, inline)]

Previous Next

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