[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22277: 'dd' - stats are not what expected
From: |
Pádraig Brady |
Subject: |
bug#22277: 'dd' - stats are not what expected |
Date: |
Thu, 31 Dec 2015 21:51:19 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
On 31/12/15 10:18, Pádraig Brady wrote:
> 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).
Resending as previous email seems dropped somewhere:
The attached auto sets the units.
For status=progress this is done based on output block size,
for the final transfer stats, it's done based on the transferred byte count.
cheers,
Pádraig
dd-stats-units.patch
Description: Text Data