Odpověď na názor

No ne, když kopíruješ celý disk/image atd. tak je to v pohodě, protože se ve čtení pokračuje dál. Problém je když používáš "count" a chceš aby to přeneslo přesně tolik dat kolik je count*bs.

Nasimulovat se to dá takhle:

$ (while sleep 0.1; do head -c 1000 /dev/urandom ; done) | dd bs=1024 count=10 of=/dev/null
dd: warning: partial read (1000 bytes); suggest iflag=fullblock
0+10 records in
0+10 records out
10000 bytes (10 kB, 9,8 KiB) copied, 1,0492 s, 9,5 kB/s

(mělo přenést 10240 a přeneslo jen 10000). Tj. stane se to pokud se čte z programu/sítě, ze kterého padají data po menších bobečcích než chceme číst.

A je to reálné při síťovém provozu, např. ssh po normálním rozumně rychlém internetu:

$ ssh f "cat /dev/urandom" | dd bs=1M count=10 of=/dev/null
dd: warning: partial read (32768 bytes); suggest iflag=fullblock
0+10 records in
0+10 records out
327680 bytes (328 kB, 320 KiB) copied, 0,527688 s, 621 kB/s

A stejně tak při čtení komprimovaného archivu:

$ zstdcat openwrt-imagebuilder-24.10.2-ramips-mt7621.Linux-x86_64.tar.zst | dd bs=1M count=10 of=/dev/null
dd: warning: partial read (65536 bytes); suggest iflag=fullblock
0+10 records in
0+10 records out
593920 bytes (594 kB, 580 KiB) copied, 0,00314817 s, 189 MB/s

Přímo disku se to doufejme dít nebude, a doufejme že ani např. z NFS share. Ale nesázel bych na to… Konec konců, diskutujeme pod zprávičkou, kdy měl někdo částečný zápis při zapisování do "pomalého" md5sum.