--- Begin Message ---
|
Subject: |
Interface inconsistency, use of intelligent defaults. |
|
Date: |
Thu, 15 May 2014 18:24:11 -0700 |
|
User-agent: |
Thunderbird |
On programs that allow input and output by specifying computer-base2 powers
of K/M/G OR decimal based powers of 10,
If the input units are specified in in powers of 2 then the output should be
given in the same units.
Example:
dd if=/dev/zero of=/dev/null bs=256M count=2
... So 512MB, total -... but what do I see:
536870912 bytes (537 MB) copied, 0.225718 s, 2.4 GB/s
Clearly 256*2 != 537.
At the very least this violates the design principle of 'least surprise'
and/or 'least astonishment'.
The SI suffixes are a pox put on us bye the disk manufacturers because
they wanted to pretend to have 2GB or 4GB drives, when they really
only have 1.8GB, or 1907MB.
Either way, disks are created in powers of 512 (or 4096) byte sectors,
, so while you can exactly specify sizes in powers of 1024, you can't
do the same with powers of 1000 (where the result mush be some multiple of
or 4096 for some new disks).
If I compare this to "df", and see my disk taking 2G, then I should
be able to xfer it to another 2G disk but this is not the case
do to immoral actions on the part of diskmakers. People knew, at the time,
that 9600 was a 960 character/second -- it was a phone communication speed
where decimal was used, but for storage, units were expressed in multples
of 512 (which the power-of-10 prefixes are not).
(Yes, I know for official purposes, and where the existing established
held sway before the advent of computers, metric-base-10 became understood
as power of 10 based, but in computers, there was never confusion until
disk manufacturers tried to take advantage of people.
Memory does not come in 'kB' mB or gB (kmg=10^(3*{1,2,3}).. it comes
in sizes of KB/MB/GB or (KMG=2^10**{1,2,3}).
But this isn't about changing all unit everywhere... but maintaining
consistency with the units the user used on input (where such can be
verified).
Reasonable? Or are inconsistent results more reasonable?
;-)
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#17505: Interface inconsistency, use of intelligent defaults. |
|
Date: |
Fri, 16 May 2014 10:37:55 +0100 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 05/16/2014 02:24 AM, Linda Walsh wrote:
> On programs that allow input and output by specifying computer-base2 powers
> of K/M/G OR decimal based powers of 10,
>
> If the input units are specified in in powers of 2 then the output should be
> given in the same units.
>
> Example:
>
> dd if=/dev/zero of=/dev/null bs=256M count=2
> ... So 512MB, total -... but what do I see:
> 536870912 bytes (537 MB) copied, 0.225718 s, 2.4 GB/s
>
> Clearly 256*2 != 537.
>
> At the very least this violates the design principle of 'least surprise'
> and/or 'least astonishment'.
I agree that the units representation is unfortunate,
but an accident of history.
POSIX species 'k' and 'b' to mean 1024 and 512 respectively.
Standards wise 'k' should really mean 1000 and 'K' 1024.
Then extending from that we now have (which we can't change for compat reasons):
k=K=kiB=KiB=1024
kb=KB=1000
M=MiB=1024^2
MB=1000^2
...
However when _outputting) the stats line we could use the
least ambiguous and most standard unit, which would be the IEC unit.
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
thanks,
Pádraig.
dd-stats-units.patch
Description: Text Data
--- End Message ---