[Toybox] dd man page

[Alain Toussaint]

Use case here:

dd if=/dev/zero of=/dev/sd[a,b,c,d,etc...] bs=64MB (could go higher)
conv=fsync status=progress

The important bit for me is the status=progress or whatever you come
up as a design to figure out disk throughput.

It's the only use I have for dd.

Al

2017-07-13 22:50 GMT-04:00 Rob Landley <rob at landley.net>:
> On 07/12/2017 03:22 AM, Rob Landley wrote:
>> Next up, a similarly close reading of the man page...
>
> Using ubuntu 14.04 as reference:
>
> Still dropping conv=ascii,ebcdic,ibm because that was already obsolete
> 30 years ago.
>
> I can see adding conv=excl,nocreat (sure, you got notrunc already)
>
> Adding conv=fsync but not conv=fdatasync (If this breaks somebody's
> script I can add it but is "sync data but not metadata" a hair we want
> to split?)
>
> Let's see... iflag and oflag= are kind of silly. There's already
> conv=excl,nocreat,excl,notrunc so why is append not there too? Why can
> you have iflag=append? "direct" is micromanaging nonsense (it was
> introduced for oracle's database code, we have sync if we want to be
> sure it hit disk). And "directory" is just nonsensical on Linux.
> (Apparently bsd can read binary directory info, but there's no _use_ for
> it?)
>
> https://lists.gnu.org/archive/html/coreutils/2014-08/msg00032.html
>
> Sigh. But somebody did dig up a use case for nonblock:
>
> https://stackoverflow.com/questions/32057396/how-to-flush-named-pipefifo-in-non-blocking-mode-in-busybox-shell-script
>
> But busybox git still doesn't implement it so there can't be that big of
> a demand? Hmmm...
>
> Alright, these _might_ make sense:
>
>   iflag=noctty,noatime,nonblock,nofollow
>   oflag=append,noctty,noatime,nonblock,
>
> These are silly:
>
>   ?flag=direct,directory,dsync,fullblock,nocache
>
> (If you want to drop caches for some sort of benchmark you can
> echo 3 > /proc/sys/vm/drop_caches)
>
> What on earth is count_bytes? answer: how dd should have worked in the
> first place? Oh this is just a terribly designed command all around.
> conv=bytes makes sense, having separate count-bytes, seek_bytes,and
> skip_bytes and having them care whether you iflags= or oflags= them is
> NONSENSE.
>
> This business with sending a signal to get status? If you want dd to
> output periodic progress reports (or a progress bar), DO THAT.
> status=bar or status=count would have been the obvious things to do.
>
> Ok, looking at the iflag/oflag things: noctty, noatime, nofollow, and
> append don't make sense to specify for input/output. If you want it for
> one you presumably want it for both. The only one that really needs to
> distinguish input from output is "nonblock" (although not for the one
> use case I could find, since /dev/null should never block...). And if we
> needed to distinguish within conv it could just have done
> conv=inonblock,ononblock.
>
> Sigh. Nobody's requested any of this stuff yet, it's not in posix, and
> even busybox hasn't bothered to implement it so far...
>
> Right, question: should I
>
> A) copy the existing insanity
>
> B) just do:
>
>   conv=append,noctty,inonblock,ononblock,nofollow,bytes
>   status=bar,count
>
> C) ignore it all and wait for people to complain about its absence?
>
> Does anybody have strong opinions on this? I'm leaning towards door #2
> myself. Posix has had 15 years to catch up on this, and declined.
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net