¿Qué hace dd conv = sync, noerror?

Entonces, ¿cuál es el caso cuando agregar conv=sync,noerrorhace una diferencia al hacer una copia de seguridad de un disco duro completo en un archivo de imagen? ¿Es conv=sync,noerrorun requisito al hacer cosas forenses? Si es así, ¿por qué es el caso con referencia a Linux Fedora?

Editar:

OK, entonces si hago dd sin conv=sync,noerror, y ddencuentro un error de lectura al leer el bloque (dimensionemos 100M), dd simplemente omite el bloque de 100M y lee el siguiente bloque sin escribir algo ( dd conv=sync,noerrorescribe ceros a 100M de salida, así que qué pasa con este caso ?)

¿Y si el hash del disco duro original y el archivo de salida son diferentes si no se realiza conv=sync,noerror? ¿O es solo cuando se produjo un error de lectura?

conv=syncle indica ddque rellene cada bloque a la izquierda con valores nulos, de modo que si, debido a un error, no se puede leer el bloque completo, se conserva la longitud completa de los datos originales, aunque no todos los datos en sí se puedan incluir en la imagen . de esa manera al menos sabe qué tan dañados están los datos, lo que podría proporcionarle pistas forenses, y si no puede tomar una imagen debido a bloques defectuosos o lo que sea, no puede analizar ninguno de los datos. Algunos es mejor que ninguno.

conv=sync,noerrores necesario para evitar dddetenerse en caso de error y realizar un volcado.conv=syncno tiene mucho sentido sin noerror.

http://linuxcommand.org/man_pages/dd1.html

http://vlinux-freak.blogspot.com/2011/01/how-to-use-dd-command.html

dd conv=sync,noerror(o conv=noerror,sync) corrompe sus datos.

Según el error de E / S encontrado y el tamaño de bloque utilizado (¿más grande que el tamaño del sector físico?), Las direcciones de entrada y salida en realidad no permanecen sincronizadas sino que terminan en los desplazamientos incorrectos, lo que hace que la copia sea inútil para las imágenes del sistema de archivos y otros cosas donde las compensaciones importan.

Muchos lugares recomiendan usar conv=noerror,synccuando se trata de discos defectuosos. Yo solía hacer la misma recomendación. A mí me funcionó, cuando tuve que recuperar un disco dañado hace algún tiempo.

Sin embargo, las pruebas sugieren que esto no es realmente confiable de ninguna manera.

Use losetupy dmsetuppara crear un A error Bdispositivo:

truncate -s 1M a.img b.img
A=$(losetup --find --show a.img)
B=$(losetup --find --show b.img)
i=0 ; while printf "A%06d\n" $i ; do i=$((i+1)) ; done > $A
i=0 ; while printf "B%06d\n" $i ; do i=$((i+1)) ; done > $B

Los dispositivos de bucle A, B se ven así:

# head -n 3 $A $B
==> /dev/loop0 <==
A000000
A000001
A000002

==> /dev/loop1 <==
B000000
B000001
B000002

Entonces, es A, B con números incrementales que nos ayudarán a verificar las compensaciones más adelante.

Ahora para poner un error de lectura entre los dos, cortesía del mapeador de dispositivos Linux:

# dmsetup create AerrorB << EOF
0 2000 linear $A 0
2000 96 error
2096 2000 linear $B 48
EOF

Este ejemplo crea AerrorBcomo en 2000sectores de A, seguido de 2*48sectores de error, seguido de 2000sectores deB .

Solo para verificar:

# blockdev --getsz /dev/mapper/AerrorB
4096
# hexdump -C /dev/mapper/AerrorB
00000000  41 30 30 30 30 30 30 0a  41 30 30 30 30 30 31 0a  |A000000.A000001.|
00000010  41 30 30 30 30 30 32 0a  41 30 30 30 30 30 33 0a  |A000002.A000003.|
[...]
000f9fe0  41 31 32 37 39 39 36 0a  41 31 32 37 39 39 37 0a  |A127996.A127997.|
000f9ff0  41 31 32 37 39 39 38 0a  41 31 32 37 39 39 39 0a  |A127998.A127999.|
000fa000
hexdump: /dev/mapper/AerrorB: Input/output error

Por lo tanto, se lee hasta A127999\n, ya que cada línea tiene 8 bytes que suman 1024000 bytes, que son nuestros 2000 sectores de 512 bytes. Todo parece estar en orden...

¿Va a mezclar?

for bs in 1M 64K 16K 4K 512 42
do
    dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.gnu-dd
    busybox dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.bb-dd
done

ddrescue /dev/mapper/AerrorB AerrorB.ddrescue

Resultados:

# ls -l
-rw-r--r-- 1 root root 2113536 May 11 23:54 AerrorB.16K.bb-dd
-rw-r--r-- 1 root root 2064384 May 11 23:54 AerrorB.16K.gnu-dd
-rw-r--r-- 1 root root 3145728 May 11 23:54 AerrorB.1M.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.1M.gnu-dd
-rw-r--r-- 1 root root 2097186 May 11 23:54 AerrorB.42.bb-dd
-rw-r--r-- 1 root root 2048004 May 11 23:54 AerrorB.42.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.gnu-dd
-rw-r--r-- 1 root root 2162688 May 11 23:54 AerrorB.64K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.64K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.ddrescue

Solo desde el tamaño de los archivos puede decir que las cosas están mal para algunos tamaños de bloque.

Sumas de control:

# md5sum *
8972776e4bd29eb5a55aa4d1eb3b8a43  AerrorB.16K.bb-dd
4ee0b656ff9be862a7e96d37a2ebdeb0  AerrorB.16K.gnu-dd
7874ef3fe3426436f19ffa0635a53f63  AerrorB.1M.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.1M.gnu-dd
94abec9a526553c5aa063b0c917d8e8f  AerrorB.42.bb-dd
1413c824cd090cba5c33b2d7de330339  AerrorB.42.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.gnu-dd
3c101af5623fe8c6f3d764631582a18e  AerrorB.64K.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.64K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.ddrescue

ddddrescuesolo está de acuerdo con los tamaños de bloque que están alineados con nuestra zona de error ( 512, 4K).

Verifiquemos los datos sin procesar.

# grep -a -b --only-matching B130000 *
AerrorB.16K.bb-dd:  2096768:B130000
AerrorB.16K.gnu-dd: 2047616:B130000
AerrorB.1M.bb-dd:   2113152:B130000
AerrorB.1M.gnu-dd:  2064000:B130000
AerrorB.42.bb-dd:   2088578:B130000
AerrorB.42.gnu-dd:  2039426:B130000
AerrorB.4K.bb-dd:   2088576:B130000
AerrorB.4K.gnu-dd:  2088576:B130000
AerrorB.512.bb-dd:  2088576:B130000
AerrorB.512.gnu-dd: 2088576:B130000
AerrorB.64K.bb-dd:  2113152:B130000
AerrorB.64K.gnu-dd: 2064000:B130000
AerrorB.ddrescue:   2088576:B130000

Si bien los datos en sí parecen estar presentes, obviamente no están sincronizados; los desplazamientos están completamente fuera de control para bs = 16K, 1M, 42,64K ... solo aquellos con desplazamiento 2088576son correctos, como se puede verificar con el dispositivo original.

# dd bs=1 skip=2088576 count=8 if=/dev/mapper/AerrorB 
B130000

¿Es este comportamiento esperado de dd conv=noerror,sync? No lo sé y las dos implementaciones ddque tenía disponibles ni siquiera están de acuerdo entre sí. El resultado es muy inútil si se usa ddcon una opción de tamaño de bloque performante.

Lo anterior fue producida usando dd (coreutils) 8.25, BusyBox v1.24.2, GNU ddrescue 1.21.