bug#22277: 'dd' - stats are not what expected

[Pádraig Brady]

unarchive 17505
forcemerge 17505 22277
stop

On 31/12/15 01:11, Mike Fiedler wrote:
>  
> Hi,
>  
> I ran one of my favorite utilities 'dd' again this evening, this time with 
> bs=1G ( IEC ) - I usually do 1M but this time I dealt with more data to be 
> copied...
> I had to copy about 215 GiB of data from one to another drive ( offset 215 
> GiB was about the end of the last partition ).
> So I did:
>  
> $  dd if=/dev/sdb of=/dev/sda bs=*1G* count=*222*
> 222+0 records in
> 222+0 records out
> 238370684928 bytes (*238 GB*) copied, 1275.03 s, 187 MB/s
> 
> When it finished, I got a bit confused, and I asked myself a question if the 
> data I requested did really get copied..  of course it did, but I was not 
> expecting 238 GB to be shown.
> To make sure I calculated the 512 byte sector end number out of the 
> 238370684928 bytes 'dd' result and compared it with the output of fdisk 
> showing the last sector of the last partition... I was fine.
>  
> I think, and many others have a same opinion, 1kB = 1000B, etc, should be 
> banned from use in the IT world, and banned from use by the sales people.
>  
> The point is, as you probably noticed, if dd is told to use IEC, let's stick 
> to IEC and not get the results in whatever artificial decimal crap....
> It can not only confuse, but utility like 'dd' should be 100% specific about 
> handling the units, and there should be not a bit of doubt when it spits out 
> the results.
> If I would use 1K in this case, I would not notice the difference - my brain 
> is simply too simple, and small, but 1G should at least result in displaying 
> 222 GiB and for sure not GB.

I have to agree, and this has come up a few times now.

The number in brackets is not exact and informational for human consumption,
so we should make an effort to be less confusing.
There was a proposed patch at:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17505#37
which auto determines the appropriate base from the amount output,
to output the number with the least amount of info loss.

There were some issues noted with that,
but IMHO they were lesser than the current issue.

We will have to be careful to not corrupt output
when switching with status=progress (due to possibly shorter status line).

I'll have another look.

thanks,
Pádraig.