¿Por qué 'dd' produce diferentes archivos para la misma memoria USB?

Acabo de guardar la restauración para Windows 8.1 en una memoria USB; ahora, he estado creando una copia de bajo nivel en mi HDD, ejecutando el siguiente comando:

sudo dd if = / dev / sdf of = / disk2 / Archive / windows8.1-restore.img bs = 4M oflag = direct

Quería verificar que mi comando 'dd' estuviera bien, así que lo volví a ejecutar dos veces, especificando ambos bs=8My bs=16M; He comprobado el tamaño y es exactamente el mismo, pero md5sum proporciona una salida diferente para los tres archivos:

c38a2b07b3d473d3f1876331edc2647b windows8.1-restore.img.4M
568e382844431eef63d4ba6dc4c2c5ac windows8.1-restore.img.8M
568e382844431eef63d4ba6dc4c2c5ac windows8.1-restore.img.16M

Creo que he desmontado la memoria USB por segunda y tercera vez.

¿Debería estar preocupado por algo?

editar

El tamaño total del archivo es 31024349184bytes en todos los casos, entiendo bs=xxxque solo controle la velocidad en caso de que uno quiera volcar todo el dispositivo / unidad USB.

— Emanuele
fuente

¿Se desmontó el palo cuando corriste ddcon él bs=4M?

— gronostaj 01 de

No. Supongo que debería haberlo hecho, ¿verdad?

— Emanuele

Bien, deberías tenerlo desmontado. (O, tal vez montado solo lectura.) Tampoco estoy seguro de dónde está obteniendo los tamaños de sus bloques. Yo usaría bs = 512. Casi siempre uso bs = 512 excepto cuando uso una unidad de CD porque pueden querer un tamaño de bloque diferente (como bs = 2048, o tal vez bs = 2352 o cualquier tamaño de bloque que se esté usando, como lo señala <A HREF = " osta .org / technology / cdqa7.htm "> Tamaños de bloques de CD </A>).

— TOOGAM

@TOOGAM Aquí se explica cómo crear enlaces .

— gronostaj 01 de

@Emanuele No creo que estés equivocado. ddSe sabe que los tamaños de bloque pequeños matan el rendimiento porque obliga a muchas más llamadas de lectura y escritura de las que de otro modo serían necesarias. Creo que gronostaj es correcto, su problema es que ha eliminado el disco con el sistema de archivos montado. Suponiendo que no ha vuelto a montar el sistema de archivos desde entonces, debería poder verificar esto volviendo a ejecutar su comando dd inicial; también debería ver una suma MD5 idéntica de esa invocación.

— un CVn

La escritura de pequeñas cantidades de datos en una unidad es lenta, por lo que los buffers del sistema escriben para confirmarlos todos a la vez más tarde. Cuando el búfer contiene suficientes datos para una operación de escritura eficiente o cuando algún proceso utiliza una syncllamada al sistema , el búfer se vacía al dispositivo.

ddrealiza una copia de bajo nivel, es decir. lee datos que están físicamente presentes en un dispositivo. No tiene en cuenta las memorias intermedias.

Si la unidad se montó cuando ejecutó dd bs=4M, entonces es posible que algunas escrituras ya estén almacenadas, pero no confirmadas. Usted ha volcado la unidad sin cambios almacenados.

umountllama syncinternamente para garantizar la integridad de los datos. Por lo general, no se accede a los dispositivos desmontados a menos que solicite explícitamente algún proceso para hacerlo, por lo que es poco probable que la unidad cambie después del desmontaje.

Luego corriste dddos veces en el disco sin montarlo en el medio. Por eso bs=8My las bs=16Mllamadas produjeron los mismos resultados.

Sin embargo, la unidad se modificó entre bs=4My bs=8Mllamadas, por lo que el primer volcado es diferente. bs=no importaba, las llamadas umountsí.

Siempre debe desmontar el dispositivo antes de usarlo, ddde lo contrario, algún otro proceso puede modificar su contenido mientras ddhace su trabajo y romper la integridad del archivo.

— gronostaj
fuente

Pensé que había sido un poco idiota al montarlo la primera vez cuando ejecuté dd. Supongo que mantendré el archivo tomado con el dispositivo desmontado . ¡De miedo!

— Emanuele