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

From: Pádraig Brady <[email-masked]>
Date: Thu, 31 Dec 2015 10:18:10 +0000

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.