On Friday 16 May 2014, Pádraig Brady wrote: > 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! What about just "512 M" which looks IMO better, is a valid input unit and is explained in the man page. cu, Rudi
