From debbugs-submit-bounces@debbugs.gnu.org Thu May 15 21:25:03 2014 Received: (at submit) by debbugs.gnu.org; 16 May 2014 01:25:03 +0000 Received: from localhost ([127.0.0.1]:36487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl6tS-0008WI-3K for submit@debbugs.gnu.org; Thu, 15 May 2014 21:25:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41583) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl6tP-0008Vp-JL for submit@debbugs.gnu.org; Thu, 15 May 2014 21:25:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wl6tB-0006qd-Ap for submit@debbugs.gnu.org; Thu, 15 May 2014 21:24:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:51361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl6tB-0006qY-7o for submit@debbugs.gnu.org; Thu, 15 May 2014 21:24:45 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl6t4-0002qE-Qx for bug-coreutils@gnu.org; Thu, 15 May 2014 21:24:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wl6sy-0006pI-Ls for bug-coreutils@gnu.org; Thu, 15 May 2014 21:24:38 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:39612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl6sy-0006oq-6L for bug-coreutils@gnu.org; Thu, 15 May 2014 21:24:32 -0400 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s4G1OE8l026480 for ; Thu, 15 May 2014 18:24:18 -0700 Message-ID: <537568BB.7010406@tlinx.org> Date: Thu, 15 May 2014 18:24:11 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: bug-coreutils@gnu.org Subject: Interface inconsistency, use of intelligent defaults. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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'. The SI suffixes are a pox put on us bye the disk manufacturers because they wanted to pretend to have 2GB or 4GB drives, when they really only have 1.8GB, or 1907MB. Either way, disks are created in powers of 512 (or 4096) byte sectors, , so while you can exactly specify sizes in powers of 1024, you can't do the same with powers of 1000 (where the result mush be some multiple of or 4096 for some new disks). If I compare this to "df", and see my disk taking 2G, then I should be able to xfer it to another 2G disk but this is not the case do to immoral actions on the part of diskmakers. People knew, at the time, that 9600 was a 960 character/second -- it was a phone communication speed where decimal was used, but for storage, units were expressed in multples of 512 (which the power-of-10 prefixes are not). (Yes, I know for official purposes, and where the existing established held sway before the advent of computers, metric-base-10 became understood as power of 10 based, but in computers, there was never confusion until disk manufacturers tried to take advantage of people. Memory does not come in 'kB' mB or gB (kmg=10^(3*{1,2,3}).. it comes in sizes of KB/MB/GB or (KMG=2^10**{1,2,3}). But this isn't about changing all unit everywhere... but maintaining consistency with the units the user used on input (where such can be verified). Reasonable? Or are inconsistent results more reasonable? ;-) From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 05:15:47 2014 Received: (at submit) by debbugs.gnu.org; 16 May 2014 09:15:47 +0000 Received: from localhost ([127.0.0.1]:36723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlEF0-0001BL-8h for submit@debbugs.gnu.org; Fri, 16 May 2014 05:15:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53073) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlEEx-0001Az-Be for submit@debbugs.gnu.org; Fri, 16 May 2014 05:15:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlEEi-0002NH-AS for submit@debbugs.gnu.org; Fri, 16 May 2014 05:15:38 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:40974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlEEi-0002NC-7u for submit@debbugs.gnu.org; Fri, 16 May 2014 05:15:28 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlEEa-0007Jm-L5 for bug-coreutils@gnu.org; Fri, 16 May 2014 05:15:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlEET-0002Bj-63 for bug-coreutils@gnu.org; Fri, 16 May 2014 05:15:20 -0400 Received: from mout.gmx.net ([212.227.15.19]:60570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlEES-00028N-Tb for bug-coreutils@gnu.org; Fri, 16 May 2014 05:15:13 -0400 Received: from zappa.ga.local ([82.139.197.16]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M7TQZ-1WxN9w36il-00xKxW for ; Fri, 16 May 2014 11:15:07 +0200 From: Ruediger Meier To: bug-coreutils@gnu.org Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. Date: Fri, 16 May 2014 11:15:06 +0200 User-Agent: KMail/1.9.10 References: <537568BB.7010406@tlinx.org> In-Reply-To: <537568BB.7010406@tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201405161115.06837.sweet_f_a@gmx.de> X-Provags-ID: V03:K0:VrfmwCdjAEbJRFaRmlhzoj7ZG+ESuTYClgsc4sfjILELYJCO4/y 7Mxwtuzv+qVKbiPgto6xDl85wuawyYhAudldXb2dyck0F28jD4BrvIEcLD0Nok4crykjr39 MO7TKMjtBvbnpuYwa438xp3qM4MNKYHNOvTBvhPlt7s6PL0bs6NuIgCm7Di7KyoFTAMnnzh +Ns65JCeqFY89BDnS/vxA== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) On Friday 16 May 2014, 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'. Yes, I also had to think again and again about this. Often being unsure whether it did what I want. Actually I would like to have a global switch or env to turn off all powers of 10 based output and input. Power of 10 is IMO only useful for the human reader to quickly understand the magnitude of byte count. For example these both lines are equally easy to read 536870912 bytes (537 MB): 536,870,912 bytes But power of 10 is annoying as well as thousands separators. The most useful and least confusing would be this one: 536870912 bytes (256 M) For the last line it's easy mental arithmetic to "calculate" that this is 537 MB. But I doubt that anybody wants to know this at all. cu, Rudi From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 05:38:33 2014 Received: (at 17505-done) by debbugs.gnu.org; 16 May 2014 09:38:33 +0000 Received: from localhost ([127.0.0.1]:36728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlEb2-0001ww-PM for submit@debbugs.gnu.org; Fri, 16 May 2014 05:38:33 -0400 Received: from mail6.vodafone.ie ([213.233.128.184]:33911) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlEaz-0001wY-8c for 17505-done@debbugs.gnu.org; Fri, 16 May 2014 05:38:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApECAEfcdVNtTc6p/2dsb2JhbAANTINVUYJwwXkBgSyDGQEBAQQjVhALDQEDAwECAQkWCwICCQMCAQIBPQgGCgMBBQIBAYhCA6wqd6RBF44+EQeCdYFLBJE4gTqII4VWhh6JIA Received: from unknown (HELO [192.168.1.79]) ([109.77.206.169]) by mail3.vodafone.ie with ESMTP; 16 May 2014 10:37:56 +0100 Message-ID: <5375DC73.9030005@draigBrady.com> Date: Fri, 16 May 2014 10:37:55 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Linda Walsh Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> In-Reply-To: <537568BB.7010406@tlinx.org> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------020100060000080906070809" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17505-done Cc: 17505-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is a multi-part message in MIME format. --------------020100060000080906070809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, Pádraig. --------------020100060000080906070809 Content-Type: text/x-patch; name="dd-stats-units.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dd-stats-units.patch" >From 4daba619de539b3d7cf43196c19e7754df9df98f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Fri, 16 May 2014 10:32:43 +0100 Subject: [PATCH] dd: output status transfer counts in IEC units IEC units are the most often used with dd, and also the least ambiguous representation. * src/dd.c (human_size): Add from/to block size params so we can reuse this function for all output size conversions. (print_stats): Use human_size() in all cases, which will change the output units from SI to IEC. Fixes http://bugs.gnu.org/17505 --- src/dd.c | 18 ++++++------------ 1 files changed, 6 insertions(+), 12 deletions(-) diff --git a/src/dd.c b/src/dd.c index 1e387f3..aafbc80 100644 --- a/src/dd.c +++ b/src/dd.c @@ -653,13 +653,13 @@ Options are:\n\ } static char * -human_size (size_t n) +human_size (size_t n, uintmax_t from_block_size, uintmax_t to_block_size) { static char hbuf[LONGEST_HUMAN_READABLE + 1]; int human_opts = (human_autoscale | human_round_to_nearest | human_base_1024 | human_space_before_unit | human_SI | human_B); - return human_readable (n, hbuf, human_opts, 1, 1); + return human_readable (n, hbuf, human_opts, from_block_size, to_block_size); } /* Ensure input buffer IBUF is allocated. */ @@ -674,7 +674,7 @@ alloc_ibuf (void) if (!real_buf) error (EXIT_FAILURE, 0, _("memory exhausted by input buffer of size %zu bytes (%s)"), - input_blocksize, human_size (input_blocksize)); + input_blocksize, human_size (input_blocksize, 1, 1)); real_buf += SWAB_ALIGN_OFFSET; /* allow space for swab */ @@ -696,7 +696,7 @@ alloc_obuf (void) if (!real_obuf) error (EXIT_FAILURE, 0, _("memory exhausted by output buffer of size %zu bytes (%s)"), - output_blocksize, human_size (output_blocksize)); + output_blocksize, human_size (output_blocksize, 1, 1)); obuf = ptr_align (real_obuf, page_size); } else @@ -734,10 +734,6 @@ multiple_bits_set (int i) static void print_stats (void) { - char hbuf[LONGEST_HUMAN_READABLE + 1]; - int human_opts = - (human_autoscale | human_round_to_nearest - | human_space_before_unit | human_SI | human_B); double delta_s; char const *bytes_per_second; @@ -766,8 +762,7 @@ print_stats (void) ngettext ("%"PRIuMAX" byte (%s) copied", "%"PRIuMAX" bytes (%s) copied", select_plural (w_bytes)), - w_bytes, - human_readable (w_bytes, hbuf, human_opts, 1, 1)); + w_bytes, human_size (w_bytes, 1, 1)); xtime_t now = gethrxtime (); if (start_time < now) @@ -776,8 +771,7 @@ print_stats (void) uintmax_t delta_xtime = now; delta_xtime -= start_time; delta_s = delta_xtime / XTIME_PRECISIONe0; - bytes_per_second = human_readable (w_bytes, hbuf, human_opts, - XTIME_PRECISION, delta_xtime); + bytes_per_second = human_size (w_bytes, XTIME_PRECISION, delta_xtime); } else { -- 1.7.7.6 --------------020100060000080906070809-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 06:01:19 2014 Received: (at 17505) by debbugs.gnu.org; 16 May 2014 10:01:19 +0000 Received: from localhost ([127.0.0.1]:36742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlEx4-0002eZ-Sw for submit@debbugs.gnu.org; Fri, 16 May 2014 06:01:19 -0400 Received: from mout.gmx.net ([212.227.17.21]:65235) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlEx2-0002eM-Dr for 17505@debbugs.gnu.org; Fri, 16 May 2014 06:01:17 -0400 Received: from zappa.ga.local ([82.139.197.16]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LkP8Z-1XMmgy2Ws7-00cTQT; Fri, 16 May 2014 12:01:07 +0200 From: Ruediger Meier To: 17505@debbugs.gnu.org, P@draigbrady.com, coreutils@tlinx.org Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. Date: Fri, 16 May 2014 12:01:06 +0200 User-Agent: KMail/1.9.10 References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> In-Reply-To: <5375DC73.9030005@draigBrady.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201405161201.06545.sweet_f_a@gmx.de> X-Provags-ID: V03:K0:/B6VUrBE48TGasylQfuF4uzvRjt4UE8A33azCrvS5ZLg0CD3tZ2 DpHDk/YB7toI8wsWfDouLI526jR39nh+KZfAcitXW7DnuIjmFQzYqYKNHXPE+zIOgUUkWnx WS68CgdZeRSCmw1fPfG5FFyycKbDMejGmrumcKiH6bG25ZTtK79FYuxl/lcghK1/xxQrs/K u1X+zbA3ggCsMLgEFzbhg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17505 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On Friday 16 May 2014, P=C3=A1draig 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=3D/dev/zero of=3D/dev/null bs=3D256M count=3D2 > > ... So 512MB, total -... but what do I see: > > 536870912 bytes (537 MB) copied, 0.225718 s, 2.4 GB/s > > > > Clearly 256*2 !=3D 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=3DK=3DkiB=3DKiB=3D1024 > kb=3DKB=3D1000 > M=3DMiB=3D1024^2 > MB=3D1000^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=3D/dev/zero of=3D/dev/null bs=3D256M count=3D2 > 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=20 and is explained in the man page. cu, Rudi From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 06:19:44 2014 Received: (at 17505) by debbugs.gnu.org; 16 May 2014 10:19:44 +0000 Received: from localhost ([127.0.0.1]:36765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlFEt-00036Q-UL for submit@debbugs.gnu.org; Fri, 16 May 2014 06:19:44 -0400 Received: from mail5.vodafone.ie ([213.233.128.176]:6998) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlFEs-000367-Bq for 17505@debbugs.gnu.org; Fri, 16 May 2014 06:19:43 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAKfldVNtTc6p/2dsb2JhbAANTIcWvmmDEQGBLIMZAQEBBCMPAUYQCw0BCgICBRYLAgIJAwIBAgFFBg0BBwEBiEKsO3ekQBeBKo0lB4J1gUsBA6Brjz4 Received: from unknown (HELO [192.168.1.79]) ([109.77.206.169]) by mail3.vodafone.ie with ESMTP; 16 May 2014 11:19:33 +0100 Message-ID: <5375E635.5040308@draigBrady.com> Date: Fri, 16 May 2014 11:19:33 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ruediger Meier Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <201405161201.06545.sweet_f_a@gmx.de> In-Reply-To: <201405161201.06545.sweet_f_a@gmx.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, coreutils@tlinx.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 05/16/2014 11:01 AM, Ruediger Meier wrote: > On Friday 16 May 2014, Pádraig Brady wrote: >> 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. That would be less clear I think since in standards notation, 512M is 512000000. Also adding the B removes any ambiguity as to whether this referred to bytes of blocks. cheers, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 17:21:02 2014 Received: (at 17505) by debbugs.gnu.org; 16 May 2014 21:21:02 +0000 Received: from localhost ([127.0.0.1]:37722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlPYs-0008JK-0S for submit@debbugs.gnu.org; Fri, 16 May 2014 17:21:02 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:33045) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlPYp-0008Iw-G3 for 17505@debbugs.gnu.org; Fri, 16 May 2014 17:21:00 -0400 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s4GLKk4K018391; Fri, 16 May 2014 14:20:50 -0700 Message-ID: <5376812A.1020209@tlinx.org> Date: Fri, 16 May 2014 14:20:42 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Pádraig Brady Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <201405161201.06545.sweet_f_a@gmx.de> <5375E635.5040308@draigBrady.com> In-Reply-To: <5375E635.5040308@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17505 Cc: Ruediger Meier , 17505@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Pádraig Brady wrote: > On 05/16/2014 11:01 AM, Ruediger Meier wrote: >> On Friday 16 May 2014, Pádraig Brady wrote: >>> 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. > > That would be less clear I think since in > standards notation, 512M is 512000000. > Also adding the B removes any ambiguity > as to whether this referred to bytes of blocks. ---- Since 'B' already refers to 2^3 (most commonly) bits of information saying "KiB" = 1024 information Bytes. What other type of bytes are there? I would acknowledge some ambiguity when using the prefixes with 'bits', but with 'Bytes' you only have their usage/reference in relation to 'information'. Note that in the information field, when referring to timings, milli, micro, nano -- all refer to an abstract, non-information quantity (time in 's'). When referring to non-computer units SI prefixes would be the default. But for space, in 'bytes' -- they are an 'information unit' that has no physical basis for measurement. I think the SI standard was too hastily pushed upon the nascent computer industry by established and more dominant companies that were used to talking about physical that relate to concrete physical quantities. I'm beginning to wonder how one would go about correcting the SI standard so as not to introduce inaccuracies in measurement in the computer industry. From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 20:14:01 2014 Received: (at 17505) by debbugs.gnu.org; 17 May 2014 00:14:01 +0000 Received: from localhost ([127.0.0.1]:50928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlSGG-00047a-9G for submit@debbugs.gnu.org; Fri, 16 May 2014 20:14:00 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:52646) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlSGD-00047M-Ny for 17505@debbugs.gnu.org; Fri, 16 May 2014 20:13:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id B1B3AA60096; Fri, 16 May 2014 17:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gisyuQZFzMh; Fri, 16 May 2014 17:13:43 -0700 (PDT) Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 18BC3A60001; Fri, 16 May 2014 17:13:43 -0700 (PDT) Message-ID: <5376A9B3.107@cs.ucla.edu> Date: Fri, 16 May 2014 17:13:39 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: P@draigBrady.com Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> In-Reply-To: <5375DC73.9030005@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Pádraig Brady wrote: > 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 I recall considering this when I added this kind of diagnostic to GNU dd back in 2004, and going with powers-of-1000 abbreviations because secondary storage devices are normally measured that way. For this reason, I expect many users will prefer powers-of-1000 here. This is particularly true for transfer rates: it's rare to see "GiB/s" in real-world prose. So it'd be unwise to make this change. The simplest thing to do is to leave "dd" alone, which is my mild preference. Alternatively, we could make the proposed behavior optional, with the default being the current behavior. If we do that, though, the behavior shouldn't be affected by the abbreviation chosen for the block size. Even if the block size is given in powers-of-1024 (which is common, because block sizes are about internal memory units, where powers-of-1024 are typical), the total number of bytes transferred and the transfer rates are more commonly interpreted in the external world, where powers-of-1000 are typical. From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 20:58:46 2014 Received: (at 17505) by debbugs.gnu.org; 17 May 2014 00:58:46 +0000 Received: from localhost ([127.0.0.1]:50963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlSxZ-0006RQ-II for submit@debbugs.gnu.org; Fri, 16 May 2014 20:58:45 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:38779) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlSxX-0006RH-F4 for 17505@debbugs.gnu.org; Fri, 16 May 2014 20:58:44 -0400 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s4H0wKx6027605; Fri, 16 May 2014 17:58:23 -0700 Message-ID: <5376B428.3020108@tlinx.org> Date: Fri, 16 May 2014 17:58:16 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Paul Eggert Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <5376A9B3.107@cs.ucla.edu> In-Reply-To: <5376A9B3.107@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, P@draigBrady.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Paul Eggert wrote: > Pádraig Brady wrote: > >> 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 > > I recall considering this when I added this kind of diagnostic to GNU > dd back in 2004, and going with powers-of-1000 abbreviations because > secondary storage devices are normally measured that way. For this > reason, I expect many users will prefer powers-of-1000 here. This is > particularly true for transfer rates: it's rare to see "GiB/s" in > real-world prose. > > So it'd be unwise to make this change. ---- When users see 512 MB copied, they expect it means 512*1024*1024. The same goes for the GB/s figure. If you went with Gb/s -- that's different, as we are more used to seeing bits/s, which is why I could go either way with that. > > > The simplest thing to do is to leave "dd" alone, which is my mild > preference. Alternatively, we could make the proposed behavior > optional, with the default being the current behavior. If we do that, > though, the behavior shouldn't be affected by the abbreviation chosen > for the block size. Even if the block size is given in powers-of-1024 > (which is common, because block sizes are about internal memory units, > where powers-of-1024 are typical), the total number of bytes > transferred and the transfer rates are more commonly interpreted in > the external world, where powers-of-1000 are typical. ---- What external world are you talking about? Where you talk about MB or GB /s outside of the computer world? If what you said was true, then people wouldn't have responded that 125MB/s was impossible (in the external world) on a 1Gb ethernet. Yet that's what 'dd' displays. See "http://superuser.com/questions/753597/fastest-way-to-copy-1tb-safely-over-the-wire/753617". See the comments under the the 2nd answer. "125MB/s is literally impossible with a 1Gbit/s line - there will be overhead..."-(Bob) and "Without very significant compression (which is only achievable on extremely low entropy data), you're never going to see 125 MB/s in any direction on GbE." (allquixotic). They don't believe 125MB/s is possible even though that's what 'dd' stated. It never occurs to people, talking about computers and speeds that someone has slipped in decimal -- it never happened before disk manufacturers wanted to inflate their figures. By not putting a stop to the nonsense that MB != 1024*1024 when disk manufacturers muddied the waters, it's led to all sorts of miscommunications. The industry leader in computing doesn't use KB to mean 1000B, nor M=10^6 ... Microsoft's disk space and rates both use 1024 based measurements. So what external world (who's opinion matters in the computer world) are you talking about? From debbugs-submit-bounces@debbugs.gnu.org Fri May 16 21:23:15 2014 Received: (at 17505) by debbugs.gnu.org; 17 May 2014 01:23:15 +0000 Received: from localhost ([127.0.0.1]:50976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlTLG-00075Z-Nq for submit@debbugs.gnu.org; Fri, 16 May 2014 21:23:15 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:55253) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlTLE-00075J-2m for 17505@debbugs.gnu.org; Fri, 16 May 2014 21:23:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 8D0E3A60063; Fri, 16 May 2014 18:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td81epASTgQw; Fri, 16 May 2014 18:22:58 -0700 (PDT) Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id DD5B6A60001; Fri, 16 May 2014 18:22:57 -0700 (PDT) Message-ID: <5376B9F1.5030207@cs.ucla.edu> Date: Fri, 16 May 2014 18:22:57 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Linda Walsh Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <5376A9B3.107@cs.ucla.edu> <5376B428.3020108@tlinx.org> In-Reply-To: <5376B428.3020108@tlinx.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, P@draigBrady.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Linda Walsh wrote: >"125MB/s is literally impossible with a 1Gbit/s line - there will be overhead" This comment is using the usual powers-of-1000 abbreviations for both the first figure (125 MB/s) and the second one (1 Gb/s), so it supports the assertion that powers-of-1000 are more common in ordinary usage. 125 MB/s is impossible is because there is some overhead at lower protocol levels, which means that you cannot possibly transfer 1 Gb of data over a 1 Gb/s line in one second, i.e., you cannot possibly transfer 125 MB of data over that line in one second, and that's what the comment says. Google is a wonderful tool, and I'm sure that if you search hard enough you will eventually find uses of powers-of-1024 abbreviations for secondary storage capacity and transfer rates. But they're rare compared to powers-of-1000 abbreviations, such as the abbreviations in the example you gave. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 04:23:44 2014 Received: (at 17505) by debbugs.gnu.org; 17 May 2014 08:23:44 +0000 Received: from localhost ([127.0.0.1]:51136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlZuB-0005dq-TJ for submit@debbugs.gnu.org; Sat, 17 May 2014 04:23:44 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:52364) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlZu9-0005df-BC for 17505@debbugs.gnu.org; Sat, 17 May 2014 04:23:42 -0400 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s4H8NNUh072991; Sat, 17 May 2014 01:23:27 -0700 Message-ID: <53771C78.3050407@tlinx.org> Date: Sat, 17 May 2014 01:23:20 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Paul Eggert Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <5376A9B3.107@cs.ucla.edu> <5376B428.3020108@tlinx.org> <5376B9F1.5030207@cs.ucla.edu> In-Reply-To: <5376B9F1.5030207@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, P@draigBrady.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Paul Eggert wrote: > Linda Walsh wrote: >> "125MB/s is literally impossible with a 1Gbit/s line - there will be > overhead" > > This comment is using the usual powers-of-1000 abbreviations for both > the first figure (125 MB/s) and the second one (1 Gb/s), so it supports > the assertion that powers-of-1000 are more common in ordinary usage. 125 > MB/s is impossible is because there is some overhead at lower protocol > levels, which means that you cannot possibly transfer 1 Gb of data over > a 1 Gb/s line in one second, i.e., you cannot possibly transfer 125 MB > of data over that line in one second, and that's what the comment says. ---- I see what you are saying, but having done that measurement myself, I can assure you the 125MB/s is exactly what 'dd' reports (using direct I/O). As I stated previously, when talking about bits, I see the decimal usage as often as not. But when people talk about timings, they want to know how long it will take to transfer the data on their disk -- given in base2 units to 'X'... Compare to 'ls', 'du', -- all give base2 units. If you think about it the only way it would be "impossible" is if they though it was 125 * 2^20. But getting 125*10^6, is relatively trivial if your overhead is < 1% -- dd won't show it. I could ask for clarification whether they were using 2^20 or 10^6 for M. But 'dd' only requires that the overhead be less than .4 or .5% to display 125. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 06:33:19 2014 Received: (at 17505) by debbugs.gnu.org; 17 May 2014 10:33:19 +0000 Received: from localhost ([127.0.0.1]:51164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlbva-0001P3-J5 for submit@debbugs.gnu.org; Sat, 17 May 2014 06:33:19 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:28130) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlbvW-0001On-UA for 17505@debbugs.gnu.org; Sat, 17 May 2014 06:33:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsCAJ06d1NtToLK/2dsb2JhbAANTA6DR1GCcIVduz0BgSCDGQEBAQMBI1YFCwsNBAMBAgEJFgsCAgkDAgECAT0IBgoDAQUCAQGINQ0Dq3p3pC0XjgIFOBEHgnWBSwSROoE6iCOFVoYeiGBBgW4 Received: from unknown (HELO [192.168.1.79]) ([109.78.130.202]) by mail2.vodafone.ie with ESMTP; 17 May 2014 11:32:57 +0100 Message-ID: <53773AD8.9090402@draigBrady.com> Date: Sat, 17 May 2014 11:32:56 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Eggert Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <5376A9B3.107@cs.ucla.edu> In-Reply-To: <5376A9B3.107@cs.ucla.edu> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------060101010708080108010708" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is a multi-part message in MIME format. --------------060101010708080108010708 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/17/2014 01:13 AM, Paul Eggert wrote: > Pádraig Brady wrote: > >> 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 > > I recall considering this when I added this kind of diagnostic to GNU dd back in 2004 > and going with powers-of-1000 abbreviations because secondary storage devices are normally > measured that way. For this reason, I expect many users will prefer powers-of-1000 here. This is a fair point as it's common to transfer MB based images in MiB sized blocks for example. Though the 512 MiB above is useful as one can immediately see that the requested amount was transferred. Also it imparts more info than 537 MB as that is trivially inferred from the previous number. Also MiB is not ambiguous wrt base, though I suppose MB isn't too bad either as MB as per standards and dd input notation is base 1000. > This is particularly true for transfer rates: it's rare to see "GiB/s" in real-world prose. Fair point. We'll leave that one as is. > > So it'd be unwise to make this change. > > The simplest thing to do is to leave "dd" alone, which is my mild preference. > Alternatively, we could make the proposed behavior optional, with the default being the current behavior. > If we do that, though, the behavior shouldn't be affected by the abbreviation chosen for the block size. > Even if the block size is given in powers-of-1024 (which is common, because block sizes are about internal > memory units, where powers-of-1024 are typical), the total number of bytes transferred and the transfer rates > are more commonly interpreted in the external world, where powers-of-1000 are typical. It's not worth a new option, but if it was to be conditional perhaps it could be based on the actual amount transferred rather than the block size. Or from a mathematical viewpoint, output the number that loses the least info. Essentially: if ((count % 1000) && ! (count % 1024)) options |= human_base_1024 The attached patch now produces: $ 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.200283 s, 2.7 GB/s $ truncate -s 256MB disk.img $ dd if=disk.img of=/dev/null bs=2M 122+1 records in 122+1 records out 256000000 bytes (256 MB) copied, 0.129617 s, 2.0 GB/s cheers, Pádraig. --------------060101010708080108010708 Content-Type: text/x-patch; name="dd-stats-units.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dd-stats-units.patch" >From 660cf3ac60674a42618ad3c7f9ae3eaec7ab90e5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Fri, 16 May 2014 10:32:43 +0100 Subject: [PATCH] dd: output base 1024 transfer counts in IEC units * src/dd.c (human_size): Add base and from/to block size params so we can reuse this function for all output size conversions. (print_stats): Use human_size() in all cases, which will change the output units from SI to IEC when the size is a power of 1024 and not a power of 1000. Fixes http://bugs.gnu.org/17505 --- src/dd.c | 31 ++++++++++++++++++------------- 1 files changed, 18 insertions(+), 13 deletions(-) diff --git a/src/dd.c b/src/dd.c index 1e387f3..f3700c9 100644 --- a/src/dd.c +++ b/src/dd.c @@ -653,13 +653,23 @@ Options are:\n\ } static char * -human_size (size_t n) +human_size (size_t n, size_t base, uintmax_t from_bs, uintmax_t to_bs) { static char hbuf[LONGEST_HUMAN_READABLE + 1]; + int human_opts = - (human_autoscale | human_round_to_nearest | human_base_1024 + (human_autoscale | human_round_to_nearest | human_space_before_unit | human_SI | human_B); - return human_readable (n, hbuf, human_opts, 1, 1); + + if (! base) + { + if ((n % 1000) && ! (n % 1024)) + human_opts |= human_base_1024; + } + else if (base == 1024) + human_opts |= human_base_1024; + + return human_readable (n, hbuf, human_opts, from_bs, to_bs); } /* Ensure input buffer IBUF is allocated. */ @@ -674,7 +684,7 @@ alloc_ibuf (void) if (!real_buf) error (EXIT_FAILURE, 0, _("memory exhausted by input buffer of size %zu bytes (%s)"), - input_blocksize, human_size (input_blocksize)); + input_blocksize, human_size (input_blocksize, 1024, 1, 1)); real_buf += SWAB_ALIGN_OFFSET; /* allow space for swab */ @@ -696,7 +706,7 @@ alloc_obuf (void) if (!real_obuf) error (EXIT_FAILURE, 0, _("memory exhausted by output buffer of size %zu bytes (%s)"), - output_blocksize, human_size (output_blocksize)); + output_blocksize, human_size (output_blocksize, 1024, 1, 1)); obuf = ptr_align (real_obuf, page_size); } else @@ -734,10 +744,6 @@ multiple_bits_set (int i) static void print_stats (void) { - char hbuf[LONGEST_HUMAN_READABLE + 1]; - int human_opts = - (human_autoscale | human_round_to_nearest - | human_space_before_unit | human_SI | human_B); double delta_s; char const *bytes_per_second; @@ -766,8 +772,7 @@ print_stats (void) ngettext ("%"PRIuMAX" byte (%s) copied", "%"PRIuMAX" bytes (%s) copied", select_plural (w_bytes)), - w_bytes, - human_readable (w_bytes, hbuf, human_opts, 1, 1)); + w_bytes, human_size (w_bytes, 0, 1, 1)); xtime_t now = gethrxtime (); if (start_time < now) @@ -776,8 +781,8 @@ print_stats (void) uintmax_t delta_xtime = now; delta_xtime -= start_time; delta_s = delta_xtime / XTIME_PRECISIONe0; - bytes_per_second = human_readable (w_bytes, hbuf, human_opts, - XTIME_PRECISION, delta_xtime); + bytes_per_second = human_size (w_bytes, 1000, XTIME_PRECISION, + delta_xtime); } else { -- 1.7.7.6 --------------060101010708080108010708-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 12:44:19 2014 Received: (at 17505) by debbugs.gnu.org; 17 May 2014 16:44:19 +0000 Received: from localhost ([127.0.0.1]:51606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlhid-0006XF-0f for submit@debbugs.gnu.org; Sat, 17 May 2014 12:44:19 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:53760) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WlhiZ-0006Wz-Ln for 17505@debbugs.gnu.org; Sat, 17 May 2014 12:44:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id DC7A3A60015; Sat, 17 May 2014 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD8-zugheT2F; Sat, 17 May 2014 09:44:01 -0700 (PDT) Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4B62639E8011; Sat, 17 May 2014 09:44:01 -0700 (PDT) Message-ID: <537791D1.4050102@cs.ucla.edu> Date: Sat, 17 May 2014 09:44:01 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <5376A9B3.107@cs.ucla.edu> <53773AD8.9090402@draigBrady.com> In-Reply-To: <53773AD8.9090402@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) Pádraig Brady wrote: > if ((count % 1000) && ! (count % 1024)) > options |= human_base_1024 Unfortunately this won't work either, as it would introduce a worse user-interface glitch: transfers of some block counts would be treated inconsistently with transfers of others. If I've done the math right: $ dd if=/dev/zero of=/dev/null count=99997 99997+0 records in 99997+0 records out 51198464 bytes (51 MB) copied, 0.101863 s, 503 MB/s $ dd if=/dev/zero of=/dev/null count=99998 99998+0 records in 99998+0 records out 51198976 bytes (49 MiB) copied, 0.0938181 s, 546 MB/s A quick glance at the output might incorrectly conclude that the first dd (51 M) transferred more data than the second dd (49 M). If we're going to make a change, perhaps it would be better to make it a separate option that ORs in human_base_1024, so that a user who prefers powers-of-1024 can alias 'dd' to 'dd status=human-readable' or whatever. From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 14:04:24 2014 Received: (at 17505) by debbugs.gnu.org; 17 May 2014 18:04:24 +0000 Received: from localhost ([127.0.0.1]:51703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wliy4-0000BP-DP for submit@debbugs.gnu.org; Sat, 17 May 2014 14:04:24 -0400 Received: from nm36-vm2.bullet.mail.bf1.yahoo.com ([72.30.238.138]:42408) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlcsi-0004CD-S9 for 17505@debbugs.gnu.org; Sat, 17 May 2014 07:34:26 -0400 Received: from [66.196.81.171] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 17 May 2014 11:34:18 -0000 Received: from [68.142.230.69] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 17 May 2014 11:34:18 -0000 Received: from [127.0.0.1] by smtp226.mail.bf1.yahoo.com with NNFMP; 17 May 2014 11:34:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400326458; bh=UwQnVdOGX//Vr/0MNf6yJR6Caxrpu4HgBzZCrzE5+hc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:Subject:To:Cc:Message-Id:In-Reply-To:References:X-Mailer:MIME-Version:Content-Type; b=rpuEgFUxgpqFHb0tDrSJmwwcJ5Xae+eyVPz9BUrxZtLtqeqtDfPwO4c8ivsTEO6J6PkAldpP5QoIqpUhh6xNT0/Vh4mKK5kJ9QrBTDgFXAG19F2s2aIMQK2tZGSkyS/TAJeavQzgBz9K6apQ6gPZww+WwlbB9Xuc9AtjdTg0mb0= X-Yahoo-Newman-Id: 289383.15274.bm@smtp226.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3eStjZcVM1nXsniqJEcgCLMoVU8RbK9tvaX7SCBsHn6EznD wKlZ72glJlqdh7Y2yiMrnjbLq0V5ShmjRdMvG1gaPRymzG65WMKBjO3JcC5T p7wV6t5aFhCqJwRi7kwAdgG9CvWC0zWTEypyJLgcoA68dkotrH8p855fyVHr 2CQYxjZNMirOk1a5Frc51PF0XsqwP6dSRE08tVFm.tScbGPc_eSzCbNF610e RKWH7U_VSQVftWuHIH0JuN0RRqx2PRwNtrw4M5nljb7JH.lvjGsS.4Ukzk7B VxGxaNDKxnVM5TibAI5JBGWM_aQc5N_mABlBU4NVSYcmrf416XgPjVa5eCYL ACcJvDE7fKl8Ao81FHc1LHhu8tc03iiDBJ_x8P7bBWN4o60YyxvtgXKk4wXs 2jR5egBVumY4.SXB4H5qWU__Yvbclzu5jphd34HNcxEvPHCeWcXgqP.mw2lT kDiz8lx1Vku_GuwwdOiGS2Hdksq6rRGIaeG58iArOMSm._9EfDn5OplaIGkS cRZuVShZe.g37PylOwT5nu_ktLufZPl4- X-Yahoo-SMTP: qWLWhsmswBAJ2u3KnYMy.7_EJg1ktIVt X-Rocket-Received: from [192.168.15.2] (lsatenstein@184.145.225.10 with plain [98.138.105.21]) by smtp226.mail.bf1.yahoo.com with SMTP; 17 May 2014 11:34:18 +0000 UTC Date: Sat, 17 May 2014 11:29:54 -0004 From: Leslie Satenstein Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. To: =?iso-8859-1?q?P=E1draig?= Brady Message-Id: <1400326434.23801.0@smtp.mail.yahoo.com> In-Reply-To: <53773AD8.9090402@draigBrady.com> References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <5376A9B3.107@cs.ucla.edu> <53773AD8.9090402@draigBrady.com> X-Mailer: geary/0.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-qep9mW/DYGqgYObtyCEA" X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: What other kinds of bytes are there. There are 9 bit bytes, with parity as a bit, and some old communication stuff with 7 bit bytes. There was also the IBM punchcard bytes. For the past 60+ years, since paper tape, bytes have been 8 bits, so we should assume that is the standard. UTF-8 is a discussion for another time. [...] Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.4 BUG6152_INVALID_DATE_TZ_ABSURD BUG6152_INVALID_DATE_TZ_ABSURD 0.6 INVALID_DATE_TZ_ABSURD Invalid Date: header (timezone does not exist) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (lsatenstein[at]yahoo.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [72.30.238.138 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 17505 X-Mailman-Approved-At: Sat, 17 May 2014 14:04:16 -0400 Cc: 17505@debbugs.gnu.org, Paul Eggert X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: What other kinds of bytes are there. There are 9 bit bytes, with parity as a bit, and some old communication stuff with 7 bit bytes. There was also the IBM punchcard bytes. For the past 60+ years, since paper tape, bytes have been 8 bits, so we should assume that is the standard. UTF-8 is a discussion for another time. [...] Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.4 BUG6152_INVALID_DATE_TZ_ABSURD BUG6152_INVALID_DATE_TZ_ABSURD 0.6 INVALID_DATE_TZ_ABSURD Invalid Date: header (timezone does not exist) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (lsatenstein[at]yahoo.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [72.30.238.138 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid --=-qep9mW/DYGqgYObtyCEA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable What other kinds of bytes are there. There are 9 bit bytes, with=20 parity as a bit, and some old communication stuff with 7 bit bytes.=20 There was also the IBM punchcard bytes.=20 For the past 60+ years, since paper tape, bytes have been 8 bits, so=20 we should assume that is the standard. UTF-8 is a discussion for=20 another time.=20 There are metric bytes (1000 bytes) which I would refer to as 000's of=20 octets, even though disk manufacturers use 000's in their offer of=20 terrabytes and not multiples of 1024. If the abbreviation (K,M,G,P) precedes 'b', as in Kb, kB, KB, and kb,=20 these abbreviations should be interpreted as appropriate multiples of=20 1024 bytes (2^10). If you absolutely want to distinguish between 2^10 vs 10^3 use Ko, kO, KO, or ko to represent the latter (000's). =20 You could apply the above rule to megabytes, 512Mb vs 512Mo and of course to Gb vs Go, Tb vs To and Pb vs Po (Peta bytes vs Peta=20 octets) All you require is one statement, all multiples of kb are multiples of=20 1024 bytes.=20 On Sat, May 17, 2014 at 6:32 AM, P=C3=A1draig Brady =20 wrote: > On 05/17/2014 01:13 AM, Paul Eggert wrote: >> P=C3=A1draig Brady wrote: >> =20 >>> The attached patch changes the output to: >>>=20 >>> $ dd if=3D/dev/zero of=3D/dev/null bs=3D256M count=3D2 >>> 2+0 records in >>> 2+0 records out >>> 536870912 bytes (512 MiB) copied, 0.152887 s, 3.3 GiB/s >> =20 >> I recall considering this when I added this kind of diagnostic to=20 >> GNU dd back in 2004 >> and going with powers-of-1000 abbreviations because secondary=20 >> storage devices are normally >> measured that way. For this reason, I expect many users will=20 >> prefer powers-of-1000 here. >=20 > This is a fair point as it's common to transfer MB based images in > MiB sized blocks for example. >=20 > Though the 512 MiB above is useful as one can immediately see that the > requested amount was transferred. Also it imparts more info than > 537 MB as that is trivially inferred from the previous number. > Also MiB is not ambiguous wrt base, though I suppose MB isn't > too bad either as MB as per standards and dd input notation is base=20 > 1000. >=20 >> This is particularly true for transfer rates: it's rare to see=20 >> "GiB/s" in real-world prose. >=20 > Fair point. We'll leave that one as is. >=20 >> =20 >> So it'd be unwise to make this change. >> =20 >> The simplest thing to do is to leave "dd" alone, which is my mild=20 >> preference. >> Alternatively, we could make the proposed behavior optional, with=20 >> the default being the current behavior. >=20 >> If we do that, though, the behavior shouldn't be affected by the=20 >> abbreviation chosen for the block size. >> Even if the block size is given in powers-of-1024 (which is common,=20 >> because block sizes are about internal >> memory units, where powers-of-1024 are typical), the total number=20 >> of bytes transferred and the transfer rates >> are more commonly interpreted in the external world, where=20 >> powers-of-1000 are typical. >=20 > It's not worth a new option, but if it was to be conditional perhaps=20 > it could be > based on the actual amount transferred rather than the block size. > Or from a mathematical viewpoint, output the number that loses the=20 > least info. > Essentially: >=20 > if ((count % 1000) && ! (count % 1024)) > options |=3D human_base_1024 >=20 > The attached patch now produces: >=20 > $ dd if=3D/dev/zero of=3D/dev/null bs=3D256M count=3D2 > 2+0 records in > 2+0 records out > 536870912 bytes (512 MiB) copied, 0.200283 s, 2.7 GB/s >=20 > $ truncate -s 256MB disk.img > $ dd if=3Ddisk.img of=3D/dev/null bs=3D2M > 122+1 records in > 122+1 records out > 256000000 bytes (256 MB) copied, 0.129617 s, 2.0 GB/s >=20 > cheers, > P=C3=A1draig. = --=-qep9mW/DYGqgYObtyCEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable What other kinds of bytes are there.  There are 9 bit bytes, with pari= ty as a bit, and some old communication stuff with 7 bit bytes. There was a= lso the IBM punchcard bytes. 

 For the past 60= + years, since paper tape, bytes have been 8 bits, so we should assume that= is the standard. UTF-8 is a discussion for another time. 

There are metric bytes (1000 bytes) which I would refer to as 000's= of octets, even though disk manufacturers use 000's in their offer of terr= abytes and not multiples of 1024.

If the abbreviation (K= ,M,G,P) precedes  'b', as in Kb, kB, KB, and kb, these abbreviations s= hould be interpreted as appropriate multiples of 1024 bytes (2^10).

If you absolutely want to distinguish between 2^10 vs 10^= 3  use
Ko, kO, KO, or ko to represent the latter (000's). &n= bsp;

You could apply the above rule to megabytes,  512Mb vs 512= Mo
and of course to Gb vs Go, Tb vs To and Pb vs Po (Peta bytes v= s Peta octets)

All you require is one statement, a= ll multiples of kb are multiples of 1024 bytes. 

<= div>
On Sat, May 17, 2014 at 6:32 AM, P=C3=A1draig Brady <P@draigBrad= y.com> wrote:
On 05/17/2014 01:13 AM, Paul Eggert wrote:
P=C3=A1draig Brady wrote: =20
The attached patch changes the output to: $ dd if=3D/dev/zero of=3D/dev/null bs=3D256M count=3D2 2+0 records in 2+0 records out 536870912 bytes (512 MiB) copied, 0.152887 s, 3.3 GiB/s
=20 I recall considering this when I added this kind of diagnostic to GNU dd b= ack in 2004 and going with powers-of-1000 abbreviations because secondary storage devi= ces are normally measured that way. For this reason, I expect many users will prefer power= s-of-1000 here.
This is a fair point as it's common to transfer MB based images in MiB sized blocks for example. Though the 512 MiB above is useful as one can immediately see that the requested amount was transferred. Also it imparts more info than 537 MB as that is trivially inferred from the previous number. Also MiB is not ambiguous wrt base, though I suppose MB isn't too bad either as MB as per standards and dd input notation is base 1000.
This is particularly true for transfer rates: it's rare to see= "GiB/s" in real-world prose.
Fair point. We'll leave that one as is.
=20 So it'd be unwise to make this change. =20 The simplest thing to do is to leave "dd" alone, which is my mild preferen= ce. Alternatively, we could make the proposed behavior optional, with the defa= ult being the current behavior.
If we do that, though, the behavior shouldn't be affected by t= he abbreviation chosen for the block size. Even if the block size is given in powers-of-1024 (which is common, becaus= e block sizes are about internal memory units, where powers-of-1024 are typical), the total number of bytes= transferred and the transfer rates are more commonly interpreted in the external world, where powers-of-1000 = are typical.
It's not worth a new option, but if it was to be conditional perhaps it cou= ld be based on the actual amount transferred rather than the block size. Or from a mathematical viewpoint, output the number that loses the least in= fo. Essentially: if ((count % 1000) && ! (count % 1024)) options |=3D human_base_1024 The attached patch now produces: $ dd if=3D/dev/zero of=3D/dev/null bs=3D256M count=3D2 2+0 records in 2+0 records out 536870912 bytes (512 MiB) copied, 0.200283 s, 2.7 GB/s $ truncate -s 256MB disk.img $ dd if=3Ddisk.img of=3D/dev/null bs=3D2M 122+1 records in 122+1 records out 256000000 bytes (256 MB) copied, 0.129617 s, 2.0 GB/s cheers, P=C3=A1draig.
= --=-qep9mW/DYGqgYObtyCEA-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 17 21:33:45 2014 Received: (at 17505) by debbugs.gnu.org; 18 May 2014 01:33:45 +0000 Received: from localhost ([127.0.0.1]:51826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlpyz-0003G1-0s for submit@debbugs.gnu.org; Sat, 17 May 2014 21:33:45 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:43727) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wlpyv-0003Fl-Eb for 17505@debbugs.gnu.org; Sat, 17 May 2014 21:33:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBACUNeFNtToLK/2dsb2JhbAANTA6HCL4KgxMBgR+DGQEBAQMBIw8BRhALDQsCAgUWCwICCQMCAQIBRQYKAwEHAQGINQ2rf3ekDheBKo0mB4J1gUsBA6Btjn5B Received: from unknown (HELO [192.168.1.79]) ([109.78.130.202]) by mail2.vodafone.ie with ESMTP; 18 May 2014 02:33:32 +0100 Message-ID: <53780DEA.6090000@draigBrady.com> Date: Sun, 18 May 2014 02:33:30 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Eggert Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults. References: <537568BB.7010406@tlinx.org> <5375DC73.9030005@draigBrady.com> <5376A9B3.107@cs.ucla.edu> <53773AD8.9090402@draigBrady.com> <537791D1.4050102@cs.ucla.edu> In-Reply-To: <537791D1.4050102@cs.ucla.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 05/17/2014 05:44 PM, Paul Eggert wrote: > Pádraig Brady wrote: >> if ((count % 1000) && ! (count % 1024)) >> options |= human_base_1024 > > Unfortunately this won't work either, as it would introduce a worse user-interface glitch: transfers of some block counts would be treated inconsistently with transfers of others. If I've done the math right: > > $ dd if=/dev/zero of=/dev/null count=99997 > 99997+0 records in > 99997+0 records out > 51198464 bytes (51 MB) copied, 0.101863 s, 503 MB/s > $ dd if=/dev/zero of=/dev/null count=99998 > 99998+0 records in > 99998+0 records out > 51198976 bytes (49 MiB) copied, 0.0938181 s, 546 MB/s Not sure how much of an issue that would be in practice. > > A quick glance at the output might incorrectly conclude that the first dd (51 M) transferred more data than the second dd (49 M). > > If we're going to make a change, perhaps it would be better to make it a separate option that ORs in human_base_1024, so that a user who prefers powers-of-1024 can alias 'dd' to 'dd status=human-readable' or whatever. Not worth an option I think, so let's leave this for now. thanks, Pádraig. From unknown Mon Jun 23 07:50:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 15 Jun 2014 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 05:44:30 2014 Received: (at control) by debbugs.gnu.org; 16 Jul 2014 09:44:30 +0000 Received: from localhost ([127.0.0.1]:56115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7LlF-00085o-Tv for submit@debbugs.gnu.org; Wed, 16 Jul 2014 05:44:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29225) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7LlD-00085f-8x for control@debbugs.gnu.org; Wed, 16 Jul 2014 05:44:28 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6G9iQVB001482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 16 Jul 2014 05:44:26 -0400 Received: from [10.36.116.33] (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6G9iOKR003633 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 16 Jul 2014 05:44:25 -0400 Message-ID: <53C64977.6090208@draigBrady.com> Date: Wed, 16 Jul 2014 10:44:23 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: control@debbugs.gnu.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) unarchive 17505 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 08:30:48 2014 Received: (at 17505) by debbugs.gnu.org; 16 Jul 2014 12:30:48 +0000 Received: from localhost ([127.0.0.1]:56208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7OMB-0006Pj-E6 for submit@debbugs.gnu.org; Wed, 16 Jul 2014 08:30:48 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:47467) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7OM9-0006PV-4z for 17505@debbugs.gnu.org; Wed, 16 Jul 2014 08:30:46 -0400 Received: by mail-wi0-f182.google.com with SMTP id d1so1227192wiv.9 for <17505@debbugs.gnu.org>; Wed, 16 Jul 2014 05:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PVrZJl3bnA6FRPw9s3wyimzdsIOZINgcJxCEC+4C2Oc=; b=Ds3e01T17sQiNYKtEvLZSmgVJCkuJR5gbQDE1Rv86hxPEDgYVApLX/qPS7ATL+y2uz vPtObYpEsO3K7ELz8vD2+tJG30rh7hkdlttAkAPwZnCs9ULXQtbincZGsQfmP1VRsbzN VqeEw/QPPluQpSKNa5R+cGTS81oGnqHcT3hFvYjGEMAhhMDEztuMNTYuBtzUsYTJrtNS jSUygA3lA44Uj8HCOLDOjb9/a7k0nXPacZv2H2HHLjrhwjHDKtrVvnjFsEADh8TUwIaK U9a9+nbRlQ6NB2gHfk8Agbjyi4zc5I7nn5UCPdhHwKEa3qO6Vl9dAY3VXMtxutF6wJ/C 5GwA== MIME-Version: 1.0 X-Received: by 10.194.7.167 with SMTP id k7mr34835151wja.11.1405513455091; Wed, 16 Jul 2014 05:24:15 -0700 (PDT) Received: by 10.216.44.210 with HTTP; Wed, 16 Jul 2014 05:24:15 -0700 (PDT) In-Reply-To: <53C647FF.2040304@draigBrady.com> References: <53C5E753.6090601@groessler.org> <53C647FF.2040304@draigBrady.com> Date: Wed, 16 Jul 2014 14:24:15 +0200 Message-ID: Subject: Re: dd statistics output From: Henrik Juul Pedersen To: =?UTF-8?Q?P=C3=A1draig_Brady?= Content-Type: multipart/alternative; boundary=047d7b5d2f7037c83304fe4e9a70 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, Christian Groessler , Coreutils X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --047d7b5d2f7037c83304fe4e9a70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christian Groessler writes: > > 268435456 bytes (256 MB) copied, ... > This would be a clear violation of the SI standard, which says on its prefixes: "These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits). The IEC has adopted prefixes for binary powers in the international standard IEC 60027-2: 2005, third edition, Letter symbols to be used in electrical technology =E2=80=93 Part 2: Telecommunications and electronics. The names and symbols for the prefixes corresponding to 210, 220, 230, 240, 250, and 260 are, respectively: kibi, Ki; mebi, Mi; gibi, Gi; tebi, Ti; pebi, Pi; and exbi, Ei. Thus, for example, one kibibyte would be written: 1 KiB =3D 210 B =3D 1024 B, where B denotes a byte. Although th= ese prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes." [1, page 121] I would second P=C3=A1draig Bradys: > > 268435456 bytes (256 MiB) copied, 0.0248346 s, 10.8 GB/s > Or as neither bit nor byte are SI units, one might even keep all IEC units in IEC binary prefix as such: > > 268435456 bytes (256 MiB) copied, 0.0248346 s, 10.1 GiB/s > Best regards Henrik Juul Pedersen [1] http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf On Wed, Jul 16, 2014 at 11:38 AM, P=C3=A1draig Brady wro= te: > On 07/16/2014 03:45 AM, Christian Groessler wrote: > > Hi, > > > > the final output of 'dd' is in "SI mode" (or how to call it). It uses > 10^6 instead of 2^20 for "megabyte". > > > > Example: > > > > $ dd if=3D/dev/zero of=3D/dev/null bs=3D65536 count=3D4096 > > 4096+0 records in > > 4096+0 records out > > 268435456 bytes (268 MB) copied, 0.0248346 s, 10.8 GB/s > > $ > > > > Is there a switch to display in "traditional" units, I'd like to have > > > > 268435456 bytes (256 MB) copied, ... > > 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. > > P=C3=A1draig. > > --047d7b5d2f7037c83304fe4e9a70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christian Groessler writes:
>
> 268435456 by= tes (256 MB) copied, ... =C2=A0
>

This would be a clear violation of the SI standard, which says on its prefi= xes:

&= quot;These SI prefixes refer strictly to powers of 10. They should not be u= sed to indicate powers of 2 (for example, one kilobit represents 1000 bits = and not 1024 bits). The IEC has adopted prefixes for binary powers in the i= nternational standard IEC 60027-2: 2005, third edition, Letter symbols to b= e used in electrical technology =E2=80=93 Part 2: Telecommunications and el= ectronics. The names and symbols for the prefixes corresponding to 210, 220= , 230, 240, 250, and 260 are, respectively: kibi, Ki; mebi, Mi; gibi, Gi; t= ebi, Ti; pebi, Pi; and exbi, Ei. Thus, for example, one kibibyte would be w= ritten: 1 KiB =3D 210 B =3D 1024 B, where B denotes a byte. Although these = prefixes are not part of the SI, they should be used in the field of inform= ation technology to avoid the incorrect usage of the SI prefixes." [1,= page 121]

I would sec= ond P=C3=A1draig Bradys:
>
>=C2=A0 268435456 bytes (256 MiB) copied, 0.0248346 s, 10.8 GB/s
>

<= div class=3D"gmail_extra">Or as neither bit nor byte are SI units, one migh= t even keep all IEC units in IEC binary prefix as such:

>
<= div class=3D"gmail_extra">>=C2=A0 268435456 bytes (256 MiB) copied, 0.0248346 s, 10.1 G= iB/s
>

<= /div>
Best regards
Henrik Juul Pedersen

[1]=C2=A0http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf


On Wed, Jul= 16, 2014 at 11:38 AM, P=C3=A1draig Brady <P@draigbrady.com> = wrote:
On 0= 7/16/2014 03:45 AM, Christian Groessler wrote:
> Hi,
>
> the final output of 'dd' is in "SI mode" (or how to = call it). It uses 10^6 instead of 2^20 for "megabyte".
>
> Example:
>
> $ dd if=3D/dev/zero of=3D/dev/null bs=3D65536 count=3D4096
> 4096+0 records in
> 4096+0 records out
> 268435456 bytes (268 MB) copied, 0.0248346 s, 10.8 GB/s
> $
>
> Is there a switch to display in "traditional" units, I'd= like to have
>
> 268435456 bytes (256 MB) copied, ...

http= ://bugs.gnu.org/17505#37 was proposed do the following automatically (d= epending on the amount output):

=C2=A0 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.

P=C3=A1draig.


--047d7b5d2f7037c83304fe4e9a70-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 09:42:28 2014 Received: (at 17505) by debbugs.gnu.org; 16 Jul 2014 13:42:28 +0000 Received: from localhost ([127.0.0.1]:56245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7PTY-0008BY-Cq for submit@debbugs.gnu.org; Wed, 16 Jul 2014 09:42:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35076) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7PTW-0008BO-Bh for 17505@debbugs.gnu.org; Wed, 16 Jul 2014 09:42:27 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6GDgOnA014514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 16 Jul 2014 09:42:24 -0400 Received: from [10.36.116.33] (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6GDgLse023685 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Jul 2014 09:42:23 -0400 Message-ID: <53C6813D.6070806@draigBrady.com> Date: Wed, 16 Jul 2014 14:42:21 +0100 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christian Groessler Subject: Re: dd statistics output References: <53C5E753.6090601@groessler.org> <53C647FF.2040304@draigBrady.com> In-Reply-To: <53C647FF.2040304@draigBrady.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 07/16/2014 10:38 AM, Pádraig Brady wrote: > On 07/16/2014 03:45 AM, Christian Groessler wrote: >> Hi, >> >> the final output of 'dd' is in "SI mode" (or how to call it). It uses 10^6 instead of 2^20 for "megabyte". >> >> Example: >> >> $ dd if=/dev/zero of=/dev/null bs=65536 count=4096 >> 4096+0 records in >> 4096+0 records out >> 268435456 bytes (268 MB) copied, 0.0248346 s, 10.8 GB/s >> $ >> >> Is there a switch to display in "traditional" units, I'd like to have >> >> 268435456 bytes (256 MB) copied, ... > > 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. 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. thanks, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 18:17:30 2014 Received: (at 17505) by debbugs.gnu.org; 16 Jul 2014 22:17:30 +0000 Received: from localhost ([127.0.0.1]:56914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7XVx-00020p-Uv for submit@debbugs.gnu.org; Wed, 16 Jul 2014 18:17:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8499) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7XVv-00020U-6m for 17505@debbugs.gnu.org; Wed, 16 Jul 2014 18:17:28 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6GMHMEc022593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 16 Jul 2014 18:17:23 -0400 Received: from [10.36.116.33] (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6GMHJqC009815 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Jul 2014 18:17:21 -0400 Message-ID: <53C6F9EF.5010101@draigBrady.com> Date: Wed, 16 Jul 2014 23:17:19 +0100 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christian Groessler Subject: Re: dd statistics output References: <53C5E753.6090601@groessler.org> <53C647FF.2040304@draigBrady.com> <53C6813D.6070806@draigBrady.com> <53C6F7FE.2060200@groessler.org> In-Reply-To: <53C6F7FE.2060200@groessler.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 07/16/2014 11:09 PM, Christian Groessler wrote: > On 07/16/14 15:42, Pádraig Brady wrote: >> 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. > > > Sorry, I cannot follow. Which inconsistent output are you referring to? > > regards, > chris It's a bit of an edge case, but if working with 1024 base quantities, rarely one might get 1000 based statistics as the selector is essentially: if ((n_written % 1000) && ! (n_written % 1024)) human_opts |= human_base_1024; So if SIGUSR1 was sent after 1000 blocks were written for example, then SI stats would be printed rather than IEC. Yes it's quite the edge case, and not especially problematic I think, but worth mentioning. thanks, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 16 20:27:55 2014 Received: (at 17505) by debbugs.gnu.org; 17 Jul 2014 00:27:55 +0000 Received: from localhost ([127.0.0.1]:56949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7ZYA-0006AI-Bt for submit@debbugs.gnu.org; Wed, 16 Jul 2014 20:27:55 -0400 Received: from vigilia.groessler.org ([79.143.177.135]:25917) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X7XNx-0001bS-0v for 17505@debbugs.gnu.org; Wed, 16 Jul 2014 18:09:14 -0400 Received: from blasi.groessler.org (gaga.groessler.org [212.168.189.235]) by vigilia.groessler.org (8.14.7/8.14.6) with ESMTP id s6GM97Md017471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 17 Jul 2014 00:09:10 +0200 (CEST) Message-ID: <53C6F7FE.2060200@groessler.org> Date: Thu, 17 Jul 2014 00:09:02 +0200 From: Christian Groessler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?P=E1draig_Brady?= Subject: Re: dd statistics output References: <53C5E753.6090601@groessler.org> <53C647FF.2040304@draigBrady.com> <53C6813D.6070806@draigBrady.com> In-Reply-To: <53C6813D.6070806@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17505 X-Mailman-Approved-At: Wed, 16 Jul 2014 20:27:53 -0400 Cc: 17505@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On 07/16/14 15:42, Pádraig Brady wrote: > 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. Sorry, I cannot follow. Which inconsistent output are you referring to? regards, chris From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 21 17:09:35 2014 Received: (at 17505) by debbugs.gnu.org; 21 Jul 2014 21:09:35 +0000 Received: from localhost ([127.0.0.1]:33754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X9Kpz-00079k-BH for submit@debbugs.gnu.org; Mon, 21 Jul 2014 17:09:35 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:46792 helo=Ishtar.hs.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X9Kpw-00079Z-3f for 17505@debbugs.gnu.org; Mon, 21 Jul 2014 17:09:33 -0400 Received: from [192.168.4.12] (athenae [192.168.4.12]) by Ishtar.hs.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s6LL9MCB013541; Mon, 21 Jul 2014 14:09:25 -0700 Message-ID: <53CD8183.6070509@tlinx.org> Date: Mon, 21 Jul 2014 14:09:23 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Pádraig Brady Subject: Re: bug#17505: dd statistics output References: <53C5E753.6090601@groessler.org> <53C647FF.2040304@draigBrady.com> <53C6813D.6070806@draigBrady.com> In-Reply-To: <53C6813D.6070806@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, Christian Groessler , coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 25 21:35:25 2014 Received: (at 17505) by debbugs.gnu.org; 26 Jul 2014 01:35:25 +0000 Received: from localhost ([127.0.0.1]:38275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XAqtP-0008UN-RV for submit@debbugs.gnu.org; Fri, 25 Jul 2014 21:35:24 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:57025 helo=Ishtar.hs.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XAqtM-0008U9-02 for 17505@debbugs.gnu.org; Fri, 25 Jul 2014 21:35:21 -0400 Received: from [192.168.4.12] (athenae [192.168.4.12]) by Ishtar.hs.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s6Q1Z84v042158; Fri, 25 Jul 2014 18:35:12 -0700 Message-ID: <53D305CD.2000109@tlinx.org> Date: Fri, 25 Jul 2014 18:35:09 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Pádraig Brady , 17505@debbugs.gnu.org, Christian Groessler , coreutils@gnu.org Subject: Pádraig: does this solve your consistency concern? (was bug#17505: dd statistics output) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.1 SUBJ_ILLEGAL_CHARS Subject: has too many raw illegal characters 0.1 SUBJECT_NEEDS_ENCODING Subject is encoded but does not specify the encoding X-Debbugs-Envelope-To: 17505 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.1 SUBJ_ILLEGAL_CHARS Subject: has too many raw illegal characters 0.1 SUBJECT_NEEDS_ENCODING Subject is encoded but does not specify the encoding 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. > > > > > From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 26 16:58:43 2014 Received: (at 17505) by debbugs.gnu.org; 26 Jul 2014 20:58:43 +0000 Received: from localhost ([127.0.0.1]:39068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XB93D-0005D8-80 for submit@debbugs.gnu.org; Sat, 26 Jul 2014 16:58:43 -0400 Received: from mail4.vodafone.ie ([213.233.128.170]:33380) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XB93A-0005Cw-Vu for 17505@debbugs.gnu.org; Sat, 26 Jul 2014 16:58:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4BAO4V1FNtTiZw/2dsb2JhbAANS4NgU4J8yGKHSQGBIIR7AQEEIw8BOQoDEAsNAQoCAgUWBAcCAgkDAgECAToLBgoDAQcBAYhDA6Ukd5ZwF4EsjiAHgnmBUQWdHoV1jwiBRw Received: from unknown (HELO [192.168.1.79]) ([109.78.38.112]) by mail3.vodafone.ie with ESMTP; 26 Jul 2014 21:58:34 +0100 Message-ID: <53D4167A.1060204@draigBrady.com> Date: Sat, 26 Jul 2014 21:58:34 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Linda Walsh Subject: Re: bug#17505: =?UTF-8?B?UMOhZHJhaWc6IGRvZXMgdGhpcyBzb2x2ZSB5b3Vy?= =?UTF-8?B?IGNvbnNpc3RlbmN5IGNvbmNlcm4/ICh3YXMgYnVnIzE3NTA1OiBkZCBzdGF0aXM=?= =?UTF-8?B?dGljcyBvdXRwdXQp?= References: <537568BB.7010406@tlinx.org> <53D305CD.2000109@tlinx.org> In-Reply-To: <53D305CD.2000109@tlinx.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, Christian Groessler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 27 13:12:26 2014 Received: (at 17505) by debbugs.gnu.org; 27 Jul 2014 17:12:26 +0000 Received: from localhost ([127.0.0.1]:39521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XBRzl-0002qZ-Qv for submit@debbugs.gnu.org; Sun, 27 Jul 2014 13:12:26 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:49373 helo=Ishtar.hs.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XBRzj-0002qO-0m for 17505@debbugs.gnu.org; Sun, 27 Jul 2014 13:12:24 -0400 Received: from [192.168.4.12] (athenae [192.168.4.12]) by Ishtar.hs.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s6RHBwK9094786; Sun, 27 Jul 2014 10:12:10 -0700 Message-ID: <53D532DE.3090907@tlinx.org> Date: Sun, 27 Jul 2014 10:11:58 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Pádraig Brady Subject: Re: bug#17505: Pádraig: does this solve your consistency concern? (was bug#17505: dd statistics output) References: <537568BB.7010406@tlinx.org> <53D305CD.2000109@tlinx.org> <53D4167A.1060204@draigBrady.com> In-Reply-To: <53D4167A.1060204@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, Christian Groessler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.6 (/) Pádraig Brady wrote: > > 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. ---- It is more common to specify transfer sizes in SI and mean IEC if you are in the US where the digital computer was created. People in the US have not adopted SI units and many wouldn't know a meter from a molehill, so SI units aren't the first thing that they are likely to be meaning. Computer scientists and the industry here, grew up with using IEC prefixes where multiples of 8 are already in use. I.e. if you are talking *bytes*, you are using base 2. It is inconsistent to switch to decimal prefixes when talking about binary numbers. OTOH, if you are talking *bits*, I would say usage meaning SI units are more common. Bytes = 2^3 bits. not 10 bits. Now I was willing to go so far as to not force incompatible or bad nomenclature upon others, but to use their own nomenclature when replying to them. If someone came up to you and spoke a question in French, would you answer them in English and make some comment about people using French by accident and they really mean to use English? If you goal was clear communication, you'd try to answer in the language they were querying in (presuming you knew it). Only giving responses in English, when you accept input in French, would likely be thought insulting. If people are that concerned to get the output they want in "SI", they might be bothered to use it on input (or read the manpage and find out how to make it happen). For those that are concerned to get the output they want in computer compatible binary, you seem to be saying they are S-O-L, which seems a poor and selfish attitude to be taking. > 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. ==== If it is for human consumption, humans like consistency -- if they speak to you in 1 language, they likely appreciate being replied to in the same .. same goes for terminology and units. If someone asks you how many kilometers it is to XXX and you come back with 38 miles, you think that's a user friendly design? > > cheers, > Pádraig. > > > From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 28 13:54:44 2014 Received: (at 17505) by debbugs.gnu.org; 28 Jul 2014 17:54:44 +0000 Received: from localhost ([127.0.0.1]:41162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XBp8B-0001Kh-PM for submit@debbugs.gnu.org; Mon, 28 Jul 2014 13:54:44 -0400 Received: from vigilia.groessler.org ([79.143.177.135]:3507) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XBp85-0001KR-Cn for 17505@debbugs.gnu.org; Mon, 28 Jul 2014 13:54:38 -0400 Received: from blasi.groessler.org (gaga.groessler.org [212.168.189.235]) by vigilia.groessler.org (8.14.7/8.14.6) with ESMTP id s6SHsRHK004136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Mon, 28 Jul 2014 19:54:29 +0200 (CEST) Message-ID: <53D68E4E.80000@groessler.org> Date: Mon, 28 Jul 2014 19:54:22 +0200 From: Christian Groessler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Walsh , =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= Subject: Re: bug#17505: =?UTF-8?B?UMOhZHJhaWc6IGRvZXMgdGhpcyBzb2x2ZSB5b3Vy?= =?UTF-8?B?IGNvbnNpc3RlbmN5CWNvbmNlcm4/ICh3YXMgYnVnIzE3NTA1OiBkZCBzdGF0aXM=?= =?UTF-8?B?dGljcyBvdXRwdXQp?= References: <537568BB.7010406@tlinx.org> <53D305CD.2000109@tlinx.org> <53D4167A.1060204@draigBrady.com> <53D532DE.3090907@tlinx.org> In-Reply-To: <53D532DE.3090907@tlinx.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 07/27/14 19:11, Linda Walsh wrote: > It is more common to specify transfer sizes in SI and mean IEC if you > are in the US where the digital computer was created. > > People in the US have not adopted SI units and many wouldn't know > a meter from a molehill, so SI units aren't the first thing that > they are likely to be meaning. Computer scientists and the industry > here, > grew up with using IEC prefixes where multiples of 8 are already in > use. I.e. if you are talking *bytes*, you are using base 2. I didn't grow up in the US, and grew up with the metric system, but when I'm talking about memory sizes I always mean IEC (2^10) and never SI (10^3). The only pitfall here are hard disk sizes where I have to remember that "they" mean SI. > > It is inconsistent to switch to decimal prefixes when talking about > binary numbers. Agreed. > > > >> 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. I don't get the reason for the dynamic switch at all. Can somebody enlighten me? regards, chris From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 28 20:17:35 2014 Received: (at 17505) by debbugs.gnu.org; 29 Jul 2014 00:17:35 +0000 Received: from localhost ([127.0.0.1]:41440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XBv6k-0004Yc-Tg for submit@debbugs.gnu.org; Mon, 28 Jul 2014 20:17:35 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:48809 helo=Ishtar.hs.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XBv6i-0004YT-H8 for 17505@debbugs.gnu.org; Mon, 28 Jul 2014 20:17:33 -0400 Received: from [192.168.4.12] (athenae [192.168.4.12]) by Ishtar.hs.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s6T0HMI3026193; Mon, 28 Jul 2014 17:17:26 -0700 Message-ID: <53D6E813.2080306@tlinx.org> Date: Mon, 28 Jul 2014 17:17:23 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Christian Groessler Subject: Re: bug#17505: Pádraig: does this solve your consistency concern? (was bug#17505: dd statistics output) References: <537568BB.7010406@tlinx.org> <53D305CD.2000109@tlinx.org> <53D4167A.1060204@draigBrady.com> <53D532DE.3090907@tlinx.org> <53D68E4E.80000@groessler.org> In-Reply-To: <53D68E4E.80000@groessler.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 17505 Cc: 17505@debbugs.gnu.org, Pádraig Brady X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Christian Groessler wrote: > On 07/27/14 19:11, Linda Walsh wrote: >> It is more common to specify transfer sizes in SI and mean IEC if you >> are in the US where the digital computer was created. >> >> People in the US have not adopted SI units and many wouldn't know >> a meter from a molehill, so SI units aren't the first thing that >> they are likely to be meaning. Computer scientists and the industry >> here, >> grew up with using IEC prefixes where multiples of 8 are already in >> use. I.e. if you are talking *bytes*, you are using base 2. > > > I didn't grow up in the US, and grew up with the metric system, but when > I'm > talking about memory sizes I always mean IEC (2^10) and never SI (10^3). > The only pitfall here are hard disk sizes where I have to remember that > "they" > mean SI. ---- I was trying to come up with some reason for Padraig's belief that people usually meant SI when using IEC prefixes for computer sizes like units bytes (2^3bits) or sectors (2^12 bits)... now what power of 10 is that? I've never heard of anyone supporting Padraig position -- so I assumed it must be some foreign country where the metric system and metric prefixes are meant to apply to non-unary and non-base-10 quantities. Pádraig: where did you get your impression? When it comes to disk space -- computers always give it in IEC -- except where they've bought the line that mixed base-2 and power-of-10 prefixes is a good thing, then they try to get others to buy into such. But reality is that one can't express disk space as a power of 10 as there is no multiple of 10 that lines up with a 512-byte multiple. I.e. the system is designed to be inaccurate and confuse the issue to make it harder for consumers to do comparisons. > I don't get the reason for the dynamic switch at all. Can somebody > enlighten me? ---- I think it was thrown in as a red herring, as I can't think of any useful case for it. Having the output vary units randomly, not at the bequest of the user, doesn't seem especially useful. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 02 22:07:50 2014 Received: (at 17505) by debbugs.gnu.org; 3 Aug 2014 02:07:51 +0000 Received: from localhost ([127.0.0.1]:55372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XDlDC-0002Mx-3V for submit@debbugs.gnu.org; Sat, 02 Aug 2014 22:07:50 -0400 Received: from ishtar.tlinx.org ([173.164.175.65]:35614 helo=Ishtar.hs.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XDlDA-0002Mo-6b for 17505@debbugs.gnu.org; Sat, 02 Aug 2014 22:07:49 -0400 Received: from [192.168.4.12] (athenae [192.168.4.12]) by Ishtar.hs.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s7327Zae019992; Sat, 2 Aug 2014 19:07:37 -0700 Message-ID: <53DD9968.7060605@tlinx.org> Date: Sat, 02 Aug 2014 19:07:36 -0700 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: Henrik Juul Pedersen Subject: Re: bug#17505: dd statistics output References: <53C5E753.6090601@groessler.org> <53C647FF.2040304@draigBrady.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17505 Cc: Christian Groessler , 17505@debbugs.gnu.org, Pádraig Brady , Coreutils X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Henrik Juul Pedersen wrote: > Christian Groessler writes: >> 268435456 bytes (256 MB) copied, ... >> > > This would be a clear violation of the SI standard, which says on its > prefixes: ---- I've given this some though and now feel that the SI system is inappropriate for computer base-2 units (bytes, (2^3 bits), and sectors (2^9 bits)). It has never been considered appropriate or intelligent to mix your bases, but that is exactly what using base10 w/base-2 units is doing. The SI system was developed for physical units -- grams, meters, liters, etc. If they want to talk a physical quantity, bits would be appropriate. But as soon as they use "Byte", they are stepping into *base 2*. Mixing base-10 prefixes with a power-of-2 quantity would be bad form in any scientific paper. the SI committee telling the computer industry how they should use 'KB', or MB.. is a bit like them telling the US what prefixes it should use in front of inches, feet, yards...etc. Does putting kilo in front of 'yards', make it an SI unit? how about measuring liquids in milliquarts? or weight in kilopounds. I think anyone thinking about those examples would say it is insane to mix power-of-10 prefixes with non-si units -- when was the last time you heard population expressed in kilopeople or megapeople. Either never or rarely, because those are not physical units -- the area of authority for the SI standard. Bytes are not physical units, nor are 'sectors'. -- they are logical amounts based a conceptual grouping of bits. By using 'Byte' or 'Sector', one is already using "base-2". Switching to base-10 for larger prefixes would be considered bad form in any other area -- yet that is what the SI folks would foist upon the computer industry. One *cannot* express disk space, accurately, with base 10 units. Doing so is inherently wrong -- and was intended to mislead from the very beginning. No disk manufacturer puts out disks where the number of bytes on the disk is a power of 10. disk space HAS to be a power of 2 on binary computers. Memory doesn't come in multiples of "10" bits or bytes. It comes in multiples of 2. Using binary prefixes with binary units is consistent, but buying into the propaganda that base10 units should be used with binary units is just dumb. > > "These SI prefixes refer strictly to powers of 10. They should not be used > to indicate powers of 2 (for example, one kilobit represents 1000 bits and > not 1024 bits). The IEC has adopted prefixes for binary powers in the > international standard IEC 60027-2: 2005, third edition, Letter symbols to > be used in electrical technology – Part 2: Telecommunications and > electronics. The names and symbols for the prefixes corresponding to 210, > 220, 230, 240, 250, and 260 are, respectively: kibi, Ki; mebi, Mi; gibi, > Gi; tebi, Ti; pebi, Pi; and exbi, Ei. Thus, for example, one kibibyte would > be written: 1 KiB = 210 B = 1024 B, where B denotes a byte. Although these > prefixes are not part of the SI, they should be used in the field of > information technology to avoid the incorrect usage of the SI prefixes." > [1, page 121] ---- I disagree. They have no jurisdiction. They are a foreign entity trying to force confusing units on the computer industry. If they want to use SI prefixes on the singular unit "bit", I'm fine with that. But mixing it with a base-2 unit is confusing, makes calculations confusing, and results in imprecision in specifying binary quantities. From unknown Mon Jun 23 07:50:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 31 Aug 2014 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 31 12:35:38 2015 Received: (at control) by debbugs.gnu.org; 31 Dec 2015 17:35:38 +0000 Received: from localhost ([127.0.0.1]:51912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEh8U-00056K-2X for submit@debbugs.gnu.org; Thu, 31 Dec 2015 12:35:38 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55591) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aEh8R-000566-Nd for control@debbugs.gnu.org; Thu, 31 Dec 2015 12:35:36 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B8260160F50 for ; Thu, 31 Dec 2015 09:35:29 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 44T598xRnVkM for ; Thu, 31 Dec 2015 09:35:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7F26F160F59 for ; Thu, 31 Dec 2015 09:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id M8d0CbwSiFzM for ; Thu, 31 Dec 2015 09:35:28 -0800 (PST) Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 64CCA160F50 for ; Thu, 31 Dec 2015 09:35:28 -0800 (PST) To: control@debbugs.gnu.org From: Paul Eggert Subject: merge 17505 and 22277 Organization: UCLA Computer Science Department Message-ID: <5685675D.8070309@cs.ucla.edu> Date: Thu, 31 Dec 2015 09:35:25 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) unarchive 17505 forcemerge 17505 22277 stop From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 19:11:15 2016 Received: (at 17505) by debbugs.gnu.org; 2 Jan 2016 00:11:15 +0000 Received: from localhost ([127.0.0.1]:33960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aF9ms-0000iV-IH for submit@debbugs.gnu.org; Fri, 01 Jan 2016 19:11:15 -0500 Received: from mail1.vodafone.ie ([213.233.128.43]:40619) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aF9mk-0000hP-Bk for 17505@debbugs.gnu.org; Fri, 01 Jan 2016 19:11:06 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroHANtxhVZtT1zR/2dsb2JhbABeKAECgj5RUmcGiFmBd6pwiRwihWoBAgKBFUwBAQEBAQGBC4Q0AQEBBBIRZgsNAQMDAQIBCRYLAgIJAwIBAgE9CAYBCQMGAgEBFgiIEQUFpFiKK4VtiwwBAQEBAQUBAQEBAQEBEwmFWoV7hDo9gnyBSQWHXo8ognKBZGqFVoQXFjSHGIU9hViBGYdJZIIOAxyBXT40AYUPAQEB Received: from unknown (HELO localhost.localdomain) ([109.79.92.209]) by mail1.vodafone.ie with ESMTP; 31 Dec 2015 18:23:16 +0000 Subject: Re: bug#22277: 'dd' - stats are not what expected To: Mike Fiedler , 17505@debbugs.gnu.org References: <1626821451524279@web20h.yandex.ru> <568500E2.6060105@draigBrady.com> From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: <56857294.5020000@draigBrady.com> Date: Thu, 31 Dec 2015 18:23:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <568500E2.6060105@draigBrady.com> Content-Type: multipart/mixed; boundary="------------050508070000030208000001" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 17505 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) This is a multi-part message in MIME format. --------------050508070000030208000001 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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). > > I'll have another look. 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. --------------050508070000030208000001 Content-Type: text/x-patch; name="dd-stats-units.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dd-stats-units.patch" >From 5885398ed2252af1ce433232e00933f15e0a318f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Fri, 16 May 2014 10:32:43 +0100 Subject: [PATCH] dd: output base 1024 transfer counts in IEC units * src/dd.c (human_size): Add "base" and "from/to block size" params so we can reuse this function for all output size conversions. (print_xfer_stats): Use IEC units for status=progress output when the obs is a multiple of 2 and not a multiple of 10. Also use IEC units for the final status summary when the number of output bytes is a power of 1024, and not a power of 1000. * tests/dd/stats.sh: Update to test status units. * NEWS: Mention the change in behavior. Fixes http://bugs.gnu.org/17505 --- NEWS | 2 ++ src/dd.c | 44 +++++++++++++++++++++++++++++--------------- tests/dd/stats.sh | 10 +++++++--- 3 files changed, 38 insertions(+), 18 deletions(-) diff --git a/NEWS b/NEWS index 5080f0f..f7d219e 100644 --- a/NEWS +++ b/NEWS @@ -45,6 +45,8 @@ GNU coreutils NEWS -*- outline -*- date --iso-8601 now uses +00:00 timezone format rather than +0000. The standard states to use this "extended" format throughout a timestamp. + dd now uses IEC units if appropriate for the human readable byte count status. + df now prefers sources towards the root of a device when eliding duplicate bind mounted entries. diff --git a/src/dd.c b/src/dd.c index a5557a8..870e938 100644 --- a/src/dd.c +++ b/src/dd.c @@ -674,13 +674,23 @@ Options are:\n\ } static char * -human_size (size_t n) +human_size (size_t n, size_t base, uintmax_t from_bs, uintmax_t to_bs) { static char hbuf[LONGEST_HUMAN_READABLE + 1]; + int human_opts = - (human_autoscale | human_round_to_nearest | human_base_1024 + (human_autoscale | human_round_to_nearest | human_space_before_unit | human_SI | human_B); - return human_readable (n, hbuf, human_opts, 1, 1); + + if (! base) + { + if ((n % 1000) && ! (n % 1024)) + human_opts |= human_base_1024; + } + else if (base == 1024) + human_opts |= human_base_1024; + + return human_readable (n, hbuf, human_opts, from_bs, to_bs); } /* Ensure input buffer IBUF is allocated. */ @@ -695,7 +705,8 @@ alloc_ibuf (void) if (!real_buf) error (EXIT_FAILURE, 0, _("memory exhausted by input buffer of size %"PRIuMAX" bytes (%s)"), - (uintmax_t) input_blocksize, human_size (input_blocksize)); + (uintmax_t) input_blocksize, + human_size (input_blocksize, 1024, 1, 1)); real_buf += SWAB_ALIGN_OFFSET; /* allow space for swab */ @@ -718,7 +729,8 @@ alloc_obuf (void) error (EXIT_FAILURE, 0, _("memory exhausted by output buffer of size %"PRIuMAX " bytes (%s)"), - (uintmax_t) output_blocksize, human_size (output_blocksize)); + (uintmax_t) output_blocksize, + human_size (output_blocksize, 1024, 1, 1)); obuf = ptr_align (real_obuf, page_size); } else @@ -749,16 +761,19 @@ multiple_bits_set (int i) /* Print transfer statistics. */ static void -print_xfer_stats (xtime_t progress_time) { - char hbuf[LONGEST_HUMAN_READABLE + 1]; - int human_opts = - (human_autoscale | human_round_to_nearest - | human_space_before_unit | human_SI | human_B); +print_xfer_stats (xtime_t progress_time) +{ double delta_s; char const *bytes_per_second; + size_t w_bytes_base = 0; /* auto for final stats. */ if (progress_time) - fputc ('\r', stderr); + { + fputc ('\r', stderr); + w_bytes_base = 1000; + if ((output_blocksize % 10) && ! (output_blocksize % 2)) + w_bytes_base = 1024; + } /* Use integer arithmetic to compute the transfer rate, since that makes it easy to use SI abbreviations. */ @@ -767,8 +782,7 @@ print_xfer_stats (xtime_t progress_time) { ngettext ("%"PRIuMAX" byte (%s) copied", "%"PRIuMAX" bytes (%s) copied", select_plural (w_bytes)), - w_bytes, - human_readable (w_bytes, hbuf, human_opts, 1, 1)); + w_bytes, human_size (w_bytes, w_bytes_base, 1, 1)); xtime_t now = progress_time ? progress_time : gethrxtime (); @@ -778,8 +792,8 @@ print_xfer_stats (xtime_t progress_time) { uintmax_t delta_xtime = now; delta_xtime -= start_time; delta_s = delta_xtime / XTIME_PRECISIONe0; - bytes_per_second = human_readable (w_bytes, hbuf, human_opts, - XTIME_PRECISION, delta_xtime); + bytes_per_second = human_size (w_bytes, 1000, XTIME_PRECISION, + delta_xtime); } else { diff --git a/tests/dd/stats.sh b/tests/dd/stats.sh index da2c2d2..7b7c856 100755 --- a/tests/dd/stats.sh +++ b/tests/dd/stats.sh @@ -63,11 +63,15 @@ for open in '' '1'; do grep '250000000 bytes .* copied' err || { cat err; fail=1; } done +# Check progress is output, and check that the correct +# IEC/SI units are used both for the progress and final status output. progress_output() { - { sleep "$1"; echo 1; } | dd bs=1 status=progress of=/dev/null 2>err - # Progress output should be for "byte ... copied", while final is "bytes ..." - grep 'byte .* copied' err + { sleep "$1"; dd status=none bs=1024 count=1 if=/dev/zero; } | + dd bs=1000 of=/dev/null status=progress 2>err + + grep -F '1000 bytes (1.0 kB) copied' err && # Progress line + grep -F '1024 bytes (1.0 KiB) copied' err # Final status line } retry_delay_ progress_output 1 4 || { cat err; fail=1; } -- 2.5.0 --------------050508070000030208000001-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 01 19:11:07 2016 Received: (at control) by debbugs.gnu.org; 2 Jan 2016 00:11:07 +0000 Received: from localhost ([127.0.0.1]:33958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aF9ml-0000iD-CI for submit@debbugs.gnu.org; Fri, 01 Jan 2016 19:11:07 -0500 Received: from mail1.vodafone.ie ([213.233.128.43]:40619) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aF9mj-0000hP-RK for control@debbugs.gnu.org; Fri, 01 Jan 2016 19:11:06 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEHADVthVZtT1zR/2dsb2JhbABeKAECgj5RIn6IeLYDhgc1akwBAQEBAQGBC0ESg3oHCipUDQIFFgsCCwMCAQIBOQYCAggNCAEBHogRnx2FRIorhW2LOYEBhFmNNAwuE4E2BZcGlw+Td2SBSgEBAQcCAYIzPoNqgVoCAQI Received: from unknown (HELO localhost.localdomain) ([109.79.92.209]) by mail1.vodafone.ie with ESMTP; 31 Dec 2015 18:02:32 +0000 To: GNU bug tracker automated control server From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: <56856DB8.4030100@draigBrady.com> Date: Thu, 31 Dec 2015 18:02:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: unarchive 17505 forcemerge 17505 22277 stop [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [213.233.128.43 listed in list.dnswl.org] 0.5 DATE_IN_PAST_24_48 Date: is 24 to 48 hours before Received: date 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: unarchive 17505 forcemerge 17505 22277 stop [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [213.233.128.43 listed in list.dnswl.org] 0.5 DATE_IN_PAST_24_48 Date: is 24 to 48 hours before Received: date 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject unarchive 17505 forcemerge 17505 22277 stop From unknown Mon Jun 23 07:50:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 30 Jan 2016 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator