bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17505: Pádraig: does this solve your consistency concern? (was bug#1


From: Pádraig Brady
Subject: bug#17505: Pádraig: does this solve your consistency concern? (was bug#17505: dd statistics output)
Date: Sat, 26 Jul 2014 21:58:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 07/26/2014 02:35 AM, Linda Walsh wrote:
> Pádraig: you may have missed this as it was a reply to
> an old thread, but, changing the subj and composing as new
> should prevent that (I hope)....
> 
> You were concerned that the user would get different outputs
> based on the previously suggested algorithm -- as well as
> possibly different output when SIGUSR1 came in.
> 
> This idea seems to solve both of those -- so if the patch that was
> proposed for this was modified in line with this suggestion,
> would there be any further problems?
> 
> 
> Linda Walsh wrote:
>> Found old bug, still open...
>>
>> Pádraig Brady wrote:
>>> On 07/16/2014 10:38 AM, Pádraig Brady wrote:
>>>  
>>>> http://bugs.gnu.org/17505#37 was proposed do the following automatically 
>>>> (depending on the amount output):
>>>>
>>>>   268435456 bytes (256 MiB) copied, 0.0248346 s, 10.8 GB/s
>>>>
>>>> However that wasn't applied due to inconsistency concerns.
>>>> I'm still of the opinion that the change above would be a net gain,
>>>> as the number in brackets is for human interpretation, and in the vast
>>>> majority of cases would be the best representation for that.
>> ----
>>    One patch that would not be inconsistent:
>>
>>    If the user uses units of a single system (i.e. doesn't use 'si' and b2 
>> units
>> in same statement), then display the summary units using the same notation 
>> the
>> user used:
>>
>> dd if=xx bs=256M
>> ...(256M copied)....
>> vs.
>> dd if=xx bs=256MB
>> ...(256MB copied)...
>>
>>> Note another reason to _not_ apply the patch is that
>>> requests to print the statistics can come async through SIGUSR1,
>>> and thus increase the chances of inconsistent output.
>> Solves this too, since the units are decided when the command is parsed,
>> so SIGUSR would use the same units as would come out on a final summary.
>>
>>
>> Or is using consistent units w/what the user users not ok?
>>
>> Note, for statements w/o units (or mixed system), there would be no reason 
>> to change
>> current behavior.

That was the original approach but is a bit worse than the dynamic approach
since it's common to specify transfer sizes in IEC units for SI sized data.

BTW I was playing devil's advocate with my mention of the SIGUSR1 inconsistency.
I'm still of the opinion that the dynamic switch of human units based on
current transferred amount is the lesser of two evils, since this output
is destined for human consumption.

cheers,
Pádraig.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]