¿Por qué se usa la opción de sincronización con el comando `dd`?

Siguiendo las instrucciones en esta página, la página mostró un ddcomando y una syncopción al final. El comando es el siguiente:

xzcat ~/ubuntu.img.xz | sudo dd of=/dev/sdX bs=32M sync

Sé qué es ddy cómo funciona, pero nunca he oído hablar de esta syncopción ni la he usado , y su entrada de página manual es como:

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

¿Qué es NULy por qué se rellena ibs-size, y por qué molestarse en rellenar los bloques de datos y usar la syncopción con el ddcomando? ¿Por qué no mantenerlo simple y fácil?

Cuando intento ejecutar syncel comando tal como está con la ubicación y los valores apropiados, aparece el siguiente error:

dd: unrecognized operand ‘sync’
Try 'dd --help' for more information. 

Estás leyendo mal el comando. Sus:

xzcat ~/ubuntu.img.xz | sudo dd of=/dev/sdX bs=32M 
sync

synces un comando separado, aquí. Ver man 1 sync:

NAME
       sync - flush file system buffers

SYNOPSIS
       sync [OPTION]

DESCRIPTION
       Force changed blocks to disk, update the super block.

Es obvio por qué se usa una vez que piensas en el almacenamiento en caché.

En cuanto a la ddopción que lees, es un valor para la convopción :

Each CONV symbol may be:
   ascii  from EBCDIC to ASCII
   ...
   sync   pad every input block with NULs  to  ibs-size;  when  used  with
          block or unblock, pad with spaces rather than NULs

Si se usó (que no lo es), se usaría así:

dd ... conv=sync

Por defecto, dd leerá los datos un bloque a la vez, posiblemente leyendo en un bloque más corto que el especificado por el usuario, ya sea al final del archivo o debido al comportamiento del dispositivo fuente; Esto se llama un registro parcial . Luego escribirá un bloque que tenga el mismo tamaño que la cantidad que leyó.

Dd repetirá esto hasta que se alcance el conteo especificado, o vea eof en la entrada, o error en la entrada o salida. Cuando finaliza, dd informa el número de registros completos y parciales que leyó y escribió.

Este comportamiento está bien para copiar un archivo ordinario dentro de un sistema de archivos o sobre una conexión de red TCP, ya que se considera una secuencia de bytes. Pero otros objetos del sistema de archivos, como los DVD sin formato y la cinta magnética, requieren tamaños de escritura que se encuentran dentro de ciertos rangos y son un múltiplo redondo de cierta cantidad (como 512 o 2048 bytes). Por ejemplo, si tiene una imagen de disco que tiene 255 pistas de 63 sectores de 512 bytes, y desea escribir en una cinta que requiere un tamaño de bloque de 1024 bytes, deberá hacer algo como

dd if=disk.img of=/dev/rmt0 bs=1k conv=sync

para asegurarse de que dd no intente escribir un bloque de 512 bytes al final. El bloque más corto al final se rellenará con ceros o espacios en blanco. El relleno con ceros es una opción segura y común. La opción de dd para rellenar con espacios en blanco es útil en una situación diferente: convertir un archivo que tiene líneas de longitud variable a uno con líneas de longitud fija.

He descubierto que el sistema Linux, no dd, almacena en caché los búferes. Por lo tanto, cuando se completa el comando dd, ejecuto sync como

sudo dd if=my.downloaded.iso of=/dev/sd(?) bs=1M && sync

No he usado ninguna opción de dd interna para provocar el vaciado del búfer. Normalmente, sin embargo, cuando estoy creando una versión USB de una distribución, soy el único en la computadora, por lo que no tengo reparos en que mi comando publicado dañe. Como ejecuto la sincronización como &&, la sincronización se realiza con derechos de sudo y estoy seguro de que el USB que creo está completo.

Puede usar la syncopción de salida, que se incluye en ddcomand, por oflagsímbolo:

xzcat ~/ubuntu.img.xz | sudo dd of=/dev/sdX bs=32M oflag=sync