dd conv=sync,noerror
(ou conv=noerror,sync
) corrompe seus dados.
Dependendo do erro de E / S encontrado e do tamanho do bloco usado (maior que o tamanho do setor físico?), Os endereços de entrada e saída não ficam sincronizados, mas acabam com os desvios incorretos, o que torna a cópia inútil para imagens do sistema de arquivos e outros coisas onde as compensações são importantes.
Muitos lugares recomendam o uso conv=noerror,sync
ao lidar com discos defeituosos. Eu costumava fazer a mesma recomendação. Funcionou para mim, quando tive que recuperar um disco defeituoso há algum tempo.
No entanto, os testes sugerem que isso não é realmente confiável de forma alguma.
Use losetup
e dmsetup
para criar um A error B
dispositivo:
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
Os dispositivos de loop A, B são assim:
# head -n 3 $A $B
==> /dev/loop0 <==
A000000
A000001
A000002
==> /dev/loop1 <==
B000000
B000001
B000002
Portanto, é A, B com números crescentes que nos ajudarão a verificar as compensações posteriormente.
Agora, para colocar um erro de leitura entre os dois, cortesia do mapeador de dispositivos Linux:
# dmsetup create AerrorB << EOF
0 2000 linear $A 0
2000 96 error
2096 2000 linear $B 48
EOF
Este exemplo cria AerrorB
como em 2000
setores de A
, seguidos por 2*48
setores de erro, seguidos por 2000
setores de B
.
Apenas 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 isso A127999\n
, ele lê até , uma vez que cada linha possui 8 bytes que totalizam 1024000 bytes, que são nossos setores de 2000 bytes de 512 bytes. Tudo parece estar em ordem ...
Será que vai misturar?
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
Somente a partir dos tamanhos dos arquivos, você pode dizer que as coisas estão erradas em alguns tamanhos de bloco.
Checksums:
# 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
dd
concorda ddrescue
apenas com tamanhos de bloco alinhados à nossa zona de erro ( 512
, 4K
).
Vamos verificar os dados brutos.
# 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
Embora os dados em si pareçam estar presentes, obviamente eles não estão sincronizados; as compensações estão completamente fora de sintonia para bs = 16K, 1M, 42,64K ... somente aquelas com compensação 2088576
estão corretas, como pode ser verificado no dispositivo original.
# dd bs=1 skip=2088576 count=8 if=/dev/mapper/AerrorB
B130000
Esse comportamento esperado é de dd conv=noerror,sync
? Eu não sei e as duas implementações que dd
eu tinha disponíveis nem sequer concordam uma com a outra. O resultado é muito inútil se você usou dd
com uma opção de tamanho de bloco de desempenho.
O acima foi produzido usando dd (coreutils) 8.25
, BusyBox v1.24.2
, GNU ddrescue 1.21
.