Réponses:
Cela signifie des blocs complets de cette bs
taille plus des blocs supplémentaires de taille inférieure à la 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 également /unix//a/17357/73443 .
0+b records out
car il b>1
s'agit généralement de lectures incomplètes lors de la lecture à partir d'un canal ou d'une autre source qui ne peuvent 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 également count=X
car le nombre compte également les blocs incomplets, ce qui n'est pas fiable sans bloc complet ...
Il existe des dizaines d'utilitaires de ligne de commande standard qui peuvent s'accrocher à un descripteur et attendre la saisie. Voilà à peu près comment ils fonctionnent tous. dd
est unique en ce qu'il peut vous montrer à quoi ressemble un descripteur en ce moment .
Personnellement, je ne comprends pas vraiment l'utilité de l' iflag=fullblock
option GNU . Je veux dire, vous pouvez simplement cat
saisir votre entrée au moins aussi facilement et sans avoir à vous soucier de la taille des blocs d' E / S.
Mais dd
peut prendre une partie d'un flux - et il peut le faire à read()
/ write()
limites 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 un seul read()
par bloc d'entrée. Si le fichier qu'il essaie de read()
ne contient pas autant de données qu'il a demandé, cela n'a pas d'importance - celui- ci read()
compte comme un bloc d'entrée. Voilà comment cela fonctionne - c'est dd
l'utilité principale de.
Quand il a fait son travail, dd
rend compte de tous les blocs d'entrée / sortie qu'il a traités. En exécutant à nouveau la commande ci-dessus, mais en supprimant stdout à la place cette fois ...
dd: warning: partial read (3 bytes); suggest iflag=fullblock
0+2 records in
2+0 records out
128 bytes (128 B) copied, 1.00161 s, 0.1 kB/s
Chaque fois, dd
cela read(0,&in,64)
read
est revenu court - parce que son descripteur de fichier stdin n'avait pas assez d'octets pour qu'il réponde à sa demande quand il l'a faite. Et donc dd
read()
0 enregistrements d'entrée complets, et 2 courts. Voilà ce que signifient ces rapports.