Feature #14190
closeddd could include a human byte size
100%
Description
While working on #14189 I took a look at how we were outputting statistics compared to other systems. When #10182 introduced scaling, it used base 2 values here. This makes sense and is what we generally want; however, while researching what others do in #14189 I found that they actually use base 10 powers. While there's a lot to say on the disagreement between the binary and base 10 prefixes, at this point we should be helpful and be consistent about what we use and switch to the 'official' prefixes that indicate powers of two rather than just leaving folks to guess as much as it may not be great.
The main impetus for doing this is to actually add a humanized version of the bytes transferred in the dd
output. While the line 111171076096 bytes transferred in 2.482440 secs (41.7GB/sec)
is useful, we can take a leaf out of the book from other dd implementations and in fact #10182 and add something similar for the total bytes transferred as well. In addition, the old format used to include a space between the unit for the throughput. We should restore this while here to make it a bit easier to read (which also matches other implementations). This now leaves the summary line looking like:
$ ./dd bs=1M if=/dev/zero of=/dev/null ^C119258+0 records in 119258+0 records out 125051076608 (116 GiB) bytes transferred in 2.843474 secs (41 GiB/sec)
Related issues
Updated by Electric Monk almost 2 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit c53c97f77356a767b8a3cec554ede591cf4074d9
commit c53c97f77356a767b8a3cec554ede591cf4074d9 Author: Robert Mustacchi <rm@fingolfin.org> Date: 2021-11-06T15:14:28.000Z 14189 want support for dd status= 14190 dd could include a human byte size Reviewed by: C Fraire <cfraire@me.com> Reviewed by: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org> Reviewed by: Andy Fiddaman <andy@omnios.org> Reviewed by: Toomas Soome <tsoome@me.com> Approved by: Gordon Ross <gordon.w.ross@gmail.com>
Updated by Jason King about 1 year ago
- Related to Bug #14977: NN_NUMBUF_SZ is too small after 12258 added