En los tutoriales en línea, a menudo se sugiere utilizar el siguiente comando para copiar un CDROM a una imagen iso:
$ dd if=/dev/dvd of=foobar.iso bs=2048
¿Por qué se debe especificar el tamaño del byte? Noté que, de hecho, 2048 es el tamaño de byte estándar para las imágenes de CDROM, pero parece que ddsin especificar bs=o count=funciona también.
¿En qué circunstancias sería problemático no especificar bs=o count=al copiar desde un dispositivo de tamaño finito?
Respuestas:
¿Cuándo es adecuado dd para copiar datos? (o, cuando se leen () y escriben () parcial) señala una advertencia importante al usar count: ddpuede copiar bloques parciales, por lo que cuando countse detenga, se detendrá después del número dado de bloques, incluso si algunos de los bloques estaban incompletos. Por lo tanto, puede terminar con menos de bs * countbytes copiados, a menos que especifique iflag=fullblock.
El tamaño de bloque predeterminado para dd es 512 bytes. countes un limite; como su pregunta sugiere que no es necesario al copiar un dispositivo de tamaño finito, y realmente está destinado a copiar solo una parte de un dispositivo.
Creo que hay dos aspectos a considerar aquí: rendimiento y recuperación de datos.
En lo que respecta al rendimiento, lo ideal es que el tamaño del bloque sea al menos igual y un múltiplo del tamaño del bloque físico subyacente (por lo tanto, 2048 bytes al leer un CD-ROM). De hecho, hoy en día también puede especificar tamaños de bloque más grandes para dar a los sistemas de almacenamiento en caché subyacentes la oportunidad de almacenar cosas por usted. Pero aumentar el tamaño del bloque significa ddtener que usar mucha más memoria, y podría ser contraproducente si está copiando a través de una red debido a la fragmentación de paquetes.
En lo que respecta a la recuperación de datos, puede recuperar más datos de un disco duro defectuoso si utiliza tamaños de bloque más pequeños; esto es lo que hacen los programas dd-rescueautomáticamente: leen bloques grandes inicialmente, pero si un bloque falla, lo vuelven a leer con tamaños de bloque más pequeños. ddno hará esto, simplemente fallará todo el bloque.
Hay un poco de culto a la carga dd. Originalmente, había dos errores cpque causaban problemas: detectaría erróneamente los archivos como escasos cuando se informaba con un tamaño de bloque distinto de 512 (Linux usaba un tamaño de bloque de 1024), y no borraba los bloques vacíos del destino al copiar desde un archivo disperso a un dispositivo de bloque.
Puede encontrar algunas referencias a esto en los primeros archivos de la lista de correo de Linux .
Entonces la gente se acostumbró a dd ser la forma correcta de manejar las imágenes de disco, y cp se quedó en el camino. Y dado que dd usa un tamaño de bloque predeterminado de 512, es lento (más lento que cp en los sistemas modernos). Pero no es obvio qué tamaño de bloque debe usar. Probablemente, en su caso, alguien ha leído que 2048 es el tamaño de bloque "natural" para un CD-ROM (es decir, los CD-ROM se dividen en 2.352 sectores de bytes que contienen 2.048 bytes de datos junto con información de corrección de errores) y ha decidido que esto es el tamaño "correcto" para usar con dd, cuando de hecho probablemente obtendría resultados más rápidos si usara un tamaño de bloque (moderadamente) más grande. De hecho, GNU cp usa un tamaño de bloque predeterminado de 64k por este motivo.
tl; dr: cp /dev/dvd foobar.iso debería funcionar bien. El tamaño de bloque predeterminado ddes 512. El único efecto que puede dejarlo solo en la mayoría de las circunstancias modernas es hacer que el proceso de copia sea más lento.
Cambiar el tamaño del bloque es una buena manera de cambiar cuánto se almacena en búfer o se lee / escribe a la vez.
Realmente no se relaciona con si es un dispositivo de bloque real o uno infinito / virtual. Se trata de cuánto desea almacenar en la memoria antes ddde escribirlo. bs=establece tanto ibs=(cuántos datos se leen a la vez) como obs=(cuántos datos se escriben a la vez). Cuanto más alto, obs=más iteraciones ibs=serán necesarias antes de tener suficientes datos para ddcomenzar a escribir en el destino.
count=Tampoco depende de otra cosa que no sea lo que quieres hacer. Controla cuántos "bloques" (medidos por ibs=) serán necesarios para ddconsiderar que su trabajo se está realizando.
ddcopiar bloques parciales, no siempre es así bs * count.
ddsin bs=2048o algún múltiplo de la misma daría un error al leer desde un dispositivo de bloque unidad de CDROM.
El uso de la opción de tamaño de bloque en ddefectivamente especifica cuántos datos se copiarán en la memoria desde el subsistema de E / S de entrada antes de intentar volver a escribir en el subsistema de E / S de salida. El resultado es el mismo (a medida que se copia todo el disco), los fragmentos solo se leen con el tamaño diferente que especifique (la mayoría de las ddimplementaciones van con un tamaño de bloque predeterminado de 512 bytes).
Si tiene grandes cantidades de memoria de reserva y aumenta el tamaño de bloque, entonces se pueden leer más fragmentos de datos sucesivamente, almacenados en búfer y vaciados al destino de salida. Un tamaño de bloque más bajo requiere más gastos generales en términos de cada lseek, memset, etc.
Su kilometraje puede variar dependiendo de donde tu if=y of=está ajustada, y el hardware que está pasando, si tiene poca memoria y así sucesivamente.
Los bs = representa el tamaño de bloque para leer o escribir. Dejar el campo intacto o no especificarlo puede parecer que hace el mismo trabajo de copia, pero hay un hecho oculto al usarlo. Por ejemplo,
En el primer caso, el uso de bloques de menor tamaño ha aumentado la velocidad de copia. Mientras que en este último, un tamaño de bloque más alto ha sido una mejor opción ya que aumenta el tamaño del sector dejando menos cantidad de sector changecomando, lo que generalmente resulta en operaciones de E / S más rápidas.
dd bs=4m iflag=fullblockvsdd bs=1111y observe las velocidades de datos sustancialmente más altas que le proporcionará la anterior. Esto se debe a que el primero se alinea con los tamaños de bloque natural en la tarjeta SD, mientras que el segundo requiere que el controlador SD lea, copie y vuelva a flashear para escribir bloques físicos parciales. La importancia defullblockno debe subestimarse, por cierto, ya que sin ella,bses solo un máximo y las lecturas parciales podrían conducir a desalineaciones persistentes posteriores.