Que signifient les deux nombres respectivement dans les statistics "a + b records" de dd?

Cela signifie que des blocs complets de cette taille de bs plus des blocs supplémentaires avec une taille plus petite que le bs.

 pushd "$(mktemp -d)" dd if=/dev/zero of=1 bs=64M count=1 # and you get a 1+0 dd if=1 of=/dev/null bs=16M # 4+0 dd if=1 of=/dev/null bs=20M # 3+1 dd if=1 of=/dev/null bs=80M # 0+1 _crap=$PWD; popd; rm -rf "$_crap"; unset _crap # frostschutz's case yes | dd of=/dev/null bs=64M count=1 # 0+1 

Edit : la réponse de frostschutz mentionne un autre cas pour générer des blocs non complets. A lire. Voir aussi https://unix.stackexchange.com/a/17357/73443 .

0+b records out pour b>1 sont généralement des lectures incomplètes lors de la lecture à partir d'un tuyau ou d'une autre source qui ne peut pas fournir bs=X de données assez rapidement. Vous pouvez forcer dd à attendre des blocs complets de données en utilisant iflag=fullblock . Cette option est particulièrement utile si vous utilisez aussi count=X car le nombre count également les blocs incomplets, donc il n'est pas fiable sans fullblock …

Il existe des dizaines d'utilitaires de command line standard qui peuvent s'accrocher à un descripteur et attendre la saisie. C'est à peu près comme ça qu'ils travaillent tous. dd est unique en ce sens qu'il peut vous montrer à quoi ressemble un descripteur en ce moment .

Personnellement, je ne comprends pas vraiment l'utilité derrière l' iflag=fullblock GNU iflag=fullblock . Je veux dire, vous pouvez simplement cat votre input au less aussi facilement et sans avoir à vous soucier de la taille des blocs d'E / S du tout.

Mais dd peut prendre une partie d'un stream – et il peut le faire aux limites read() / write() sur un système raisonnablement moderne.

 { ( sleep 1 #don't write() til dd is definitely setup printf 123 #write() 3 bytes printf %-30s\\n 456 #write() 31 bytes printf you\ there\? #write() 10 bytes )| dd bs=64 count=2 conv=sync| #2 64 byte read()/write() \0-padded blocks od -vtc #show it with octal radices } 2>/dev/null #drop stderr 

 0000000 1 2 3 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000100 4 5 6 0000120 \n \0 0000140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000160 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000200 

dd fait une seule read() par bloc d'input. Si le file qu'il essaie de read() n'a pas autant de données qu'il a demandé, cela n'a pas d'importance – l' une read() count comme un bloc d'input. C'est comme ça que ça marche, c'est l'utilitaire principal de dd .

Quand il a fait son travail, dd rend count de tous les blocs d'input / sortie traités. Exécuter la command ci-dessus à nouveau, mais en supprimant stdout à la place cette fois-ci …

 dd: warning: partial read (3 bytes); suggest iflag=fullblock 0+2 records in 2+0 records out 128 bytes (128 B) copyd, 1.00161 s, 0.1 kB/s 

Chaque fois que dd a read(0,&in,64) read est revenu court – parce que son descripteur de file stdin n'avait pas suffisamment d'octets pour qu'il réponde à sa requête quand il l'a fait. Et donc dd read() 0 inputs complètes et 2 courtes. C'est ce que signifient ces rapports.