Perché il piping di `tar` in` dd` non si ferma finché il disco non è pieno?

Ho un archivio tar di una singola immagine del disco. L'immagine all'interno di questo file tar ha una dimensione di circa 4 GB. Inoltro l'output di tar xfin ddper scrivere l'immagine del disco su una scheda SD. Il discdump non si ferma mai fino a quando la scheda non è piena. Ecco la mia sessione di shell:

$ ls -l disk.img.tgz
-rw-r--r-- 1 confus confus 192M Okt  5 00:53

$ tar -tvf disk.img.tgz
-rw-r--r-- root/root 4294968320 2018-10-05 00:52 disk.img

$ lsblk -lb /dev/sdc
NAME MAJ:MIN RM        SIZE RO TYPE MOUNTPOINT
sdc    8:32   1 16022241280  0 disk

$ tar zxf disk.img.tgz -O | sudo dd status=progress conv=sync bs=1M of=/dev/sdc
[sudo] password for user: 
15992881152 bytes (16 GB, 15 GiB) copied, 212 s, 75,4 MB/s 
dd: error writing '/dev/sdc': No space left on device
0+15281 records in
15280+0 records out
16022241280 bytes (16 GB, 15 GiB) copied, 217,67 s, 73,6 MB/s

Perché? Dovrebbe fermarsi dopo che hit ha scritto l'immagine da 4 GB sul carrello da 16 GB e non ha mai esaurito lo spazio!

È perché stai sbagliando.

Stai usando, bs=1Mma la lettura da stdin, pipe, avrà letture più piccole. In effetti, secondo dd, non hai ottenuto una sola lettura completa.

E poi hai conv=syncquali complementi letture incomplete con zero.

0+15281 records in
15280+0 records out

ddha ricevuto 0 letture complete e 15281 incomplete e ha scritto 15280 blocchi completi (conv = sync zero riempito). Quindi l'output è molto più grande dell'input, fino a quando non avrai più spazio.

   sync   pad  every  input  block  with  NULs to ibs-size; when used with
          block or unblock, pad with spaces rather than NULs

Per risolvere questo, è possibile rimuovere conv=synce aggiungere iflag=fullblock.

Per illustrare, si consideri yesche per impostazione predefinita viene emesso "y \ ny \ ny \ n" infinito.

$ yes
y
y
y
^C
$ yes | hexdump -C
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*

Con dd bs=1M conv=syncsembra così:

$ yes | dd bs=1M conv=sync | hexdump -C
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
0001e000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
00112000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

Quindi ottiene un blocco incompleto di "y \ ny \ ny \ n" (0x00000 - 0x1e000, 122880 byte) quindi scrive i restanti 1M come zero (0x01e000 - 0x100000, 925696 byte). Nella maggior parte dei casi, non vuoi che ciò accada. Il risultato è comunque casuale poiché non hai alcun controllo reale su quanto ogni lettura sarebbe incompleta. Come qui la seconda lettura non è più 122880 byte ma 73728 byte.

dd conv=syncè raramente utile e anche nei casi in cui sarebbe il benvenuto, come scrivere zero quando si ottengono errori di lettura, le cose andranno terribilmente male.