¿Qué significan los dos numbers respectivamente en las statistics de "a + b records" de dd?

Las primeras 2 líneas en dd stats tienen el siguiente formatting:

 a+b records in c+d records out 

¿Por qué 2 valores numéricos? ¿Qué significa este signo más? Por lo general, es a+0 , pero a veces, cuando uso un tamaño de bloque mayor, dd imprime 0+b records out

Significa bloques completos de ese tamaño bs más bloques extra con un tamaño más pequeño que el 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 

Editar : la respuesta de frostschutz menciona otro caso para generar bloques no completos. Vale la pena leer. Ver también https://unix.stackexchange.com/a/17357/73443 .

0+b records out para b>1 suelen ser lecturas incompletas mientras se lee desde un conducto u otra fuente que no puede proporcionar bs=X de datos lo suficientemente rápido. Puede forzar a dd a esperar bloques completos de datos usando iflag=fullblock . Esta opción es particularmente útil si también está usando count=X ya que count también count bloques incompletos por lo que no es confiable sin fullblock …

Hay docenas de utilidades de command-line estándar que pueden colgar en un descriptor y esperar la input. Así es como funcionan todos. dd es único en el sentido de que puede mostrarle cómo se ve un descriptor en este momento .

Personalmente, realmente no entiendo la utilidad detrás de la opción iflag=fullblock GNU. Es decir, puedes get tus comentarios al less con la misma facilidad y sin tener que preocuparte por el tamaño del bloque E / S.

Pero dd puede tomar parte de una secuencia, y puede hacerlo en los límites de read() / write() en un sistema razonablemente moderno.

 { ( 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 hace una sola read() por bloque de input. Si el file que trata de read() no tiene tantos datos como lo ha solicitado, no importa: el que read() count como un bloque de input. Así es como funciona: esa es la utilidad principal de dd .

Cuando ha hecho su trabajo, dd informa sobre todos los bloques de input / salida con los que ha tratado. Ejecutando el command de arriba otra vez, pero dejando de usar stdout esta vez …


 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 

Cada vez que ddread(0,&in,64) read volvió breve, porque su descriptor de file stdin no tenía suficientes bytes esperando que cumpliera con su request cuando lo hizo. Y así dd read() 0 loggings de input completos y 2 cortos. Eso es lo que significan esos informes.