Seriously, it's a weird obtuse command. Weird syntax that doesn't match anything else, and the block size shouldn't be needed 99% of the time. A modern tool should figure out a good value on its own, either by interrogating the devices at both ends, or by benchmarking, or both.
* https://jdebp.uk/Softwares/dd-with-getopt.html
It only took 52 years. My prediction stands, by the way. (-:
`dd` is a real power user command, I’d prefer that it isn’t doing “intelligent” things, especially not by default.
In general, I don't see the point in manually specifying block sizes most of the time. What I want nearly always the maximum performance, and that should be possible to derive from the hardware, and/or benchmarking.
What about uses like say, skipping data? seek= and skip= are in block sizes, that may not be ideal for performance.
A smart tool should be able to write in 1 MB blocks and yet still skip 512 bytes.
cp file.iso /dev/sda cat foo.img > /dev/sda
Whatever behaviour you’re describing is not how POSIX mandates cp to work. In fact you can do this with busybox too.
cp will open("/dev/sda", O_WRONLY | O_TRUNC) and simply start writing to that file descriptor.
&& sync
If you want to be more targeted:
blockdev --flushbufs /dev/sda