este problema se puede resolver de diferentes maneras, pero nosotros te damos la que en nuestra opinión es la solución más completa.
Solución:
Desde la primera línea podemos decir dd ha leído y escrito 1,5 GB en un segundo. Incluso un SSD no puede escribir tan rápido.
Lo que sucedió es que el dispositivo de bloque /dev/sdc lo aceptó (reescritura), pero no lo envió al disco, sino que lo almacenó en búfer y comenzó a escribir en el disco a la velocidad que el disco puede soportar. Algo así como 3MiB/s.
El sistema no puede almacenar datos de forma indefinida de esa manera, solo hay una cantidad limitada de datos que aceptará mantener en ese no comprometido sucio Expresar. Entonces, después de un tiempo (en su caso, después de que se hayan escrito más de 1.5 GB pero hayan pasado menos de 2 segundos (ya que las líneas de progreso se escriben cada segundo)), dd‘s write() la llamada al sistema se bloqueará hasta que los datos se hayan descargado en el disco (durante el cual no puede escribir mensajes de progreso). Cuando pasa, dd puede enviar los pocos megabytes adicionales que faltan, y eso sucede en menos de un segundo, por lo que solo obtiene una línea de progreso adicional.
Para ver un comportamiento diferente, puede forzar que las escrituras sean síncronas, es decir, que no regresen a menos que los datos se hayan enviado al disco. Por ejemplo usando oflag=sync o oflag=dsync o oflag=direct (aunque no es que aconsejaría hacer eso).
Cuando escribe un archivo en un dispositivo de bloque, use dd con oflag=direct. Esto usa escrituras O_DIRECT, lo que evita usar su RAM como caché de reescritura. Tenga en cuenta que para obtener un buen rendimiento, oflag=direct por lo general necesita un tamaño de bloque grande.
Esto evitará ver un progreso increíblemente rápido, a menos que tenga un dispositivo extraño que tenga una caché de RAM muy grande.
Muchos dispositivos tienen una pequeña cantidad de caché. En este caso oflag=direct mostrará una realidad calificar de progreso Esto es más significativo, pero no te dice todo tu quieres saber :-). No garantiza que las últimas escrituras hayan terminado cuando dd dice que está terminado. Puede asegurarse de que todas las escrituras estén terminadas, y también verificar si hay errores de escritura, usando la opción conv=fsync. Esto llama a fsync() al final para asegurarse de que se vacíe el caché. Aquí hay un ejemplo:
dd if=my.iso of=/dev/sdc oflag=direct bs=4M status=progress conv=fsync
Algunas personas manejan el sync comando después, y comprensiblemente no se moleste en recordar conv=fsync. Esto no es tan bueno. sync no informará si una de las escrituras falló.
Si el dispositivo tiene una caché de RAM muy grande, tendría que usar oflag=direct,sync. Pero normalmente pienso en oflag=sync como una barrera potencial para el desempeño. Es posible que desee aumentar aún más el tamaño del bloque para disminuir la frecuencia de los vaciados de caché. Al realizar E/S muy síncrona y leer varios bloques de hardware en un momento como este, es posible que desee utilizar el doble búfer para mantener un buen rendimiento, es decir, utilizar un segundo dd comando como en el enlace de abajo.
A veces, es posible que también desee canalizar una imagen de disco desde otro programa, como gunzip. En este caso, el buen desempeño también depende de iflag=fullblock y canalizando a través de otro dd mando. Hay un ejemplo completo en la respuesta aquí: ¿Por qué un gunzip to dd pipeline se ralentiza al final?
Aquí puedes ver las reseñas y valoraciones de los lectores
Acuérdate de que te concedemos valorar este tutorial .