Is there any difference between doing i.e. dd bs=4M if=archlinux.iso of=/dev/sdx status=progress oflag=sync
or doing cp archlinux.iso /dev/sdx && sync
, and reason to use one over the other? (aside from the pretty progress bar in dd)

- 229
2 Answers
One difference is efficiency, and thus speed. For example, you could get the bytes one by one and copy them to the device, with cat
if it had the idealized implementation or in older systems, for example BSD4:
cat archlinux.iso > /dev/sdx
In these implementations cat
will move each byte independently. That is a slow process, although in practice there will be buffers involved. Note that modern cat
implementations will read blocks (see below).
With dd
and a good block size it will be faster.
With cp
it depends on the buffer size used by cp
(not under your control) and other buffers on the way. The efficiency lies between the idealized implementation of cat
and dd
with the optimum block size.
In practice though modern cat
and cp
will ask the system for the preferred block size: st_blksize. Note that this doesn't have to be the optimum block size.
An analogy: it is like pouring the contents of a glass into another glass.
idealized
cat
would do it one drop at a time.dd
will use a spoon, and you define exactly how big the spoon is (system limits apply)cp
and moderncat
will use its own spoon (stat -f -c %s filename
will tell you how big it is).

- 12,834
-
2
-
This answer is completely false. "In theory cat will move each byte independently." - No, it will not.
cat
reads and writes blocks just likedd
andcp
do. Moderncat
(e.g. GNUcat
) actually asks the OS what the preferred block size is, for optimum speed. On my system,cat
uses 128KiB blocks, compared todd
which only moves 512 bytes at a time. There's no reason to usedd
here. And where it matters, it's slower except if you manually match the block size. – marcelm Feb 25 '22 at 19:09 -
"With
dd
and a good block size (usually related to the physical block size) it will be faster." - More misunderstandings; optimal block size is completely unrelated to physical block size (typically 512B, sometimes 4kB). The OS will take larger amounts of data and write it out to multiple physical blocks, no problem. The concerns for userspace applications in choosing block size have to do with 1) minimizing the number of system calls and 2) optimizing CPU cache usage. This is whycat
uses 128KiB; large enough that the number of syscalls is small, and fits CPU caches well. – marcelm Feb 25 '22 at 19:16 -
@marcelm thanks for the input. I hope the edit and the links make it clearer. – Eduardo Trápani Mar 02 '22 at 05:00
I use it mainly because of the status=progress
you mentioned; what can I say, I am impatient and need to know :-)
Even if you forgot to add that and started the job, you can send it a SIGUSR1 signal and it will print the current I/O statistics to stderr (which, unless you redirected it, is your terminal).
/dev/sda
, not indd
.cp
can do the job just as well. – Gilles 'SO- stop being evil' Dec 20 '19 at 14:55cat
andcp
write blocks with 4096 bytes but the tool that is really writing to the device might do something else. – sudodus Dec 20 '19 at 15:40