dd conv = sync, noerror는 무엇을합니까?

따라서 추가 conv=sync,noerror할 때 전체 하드 디스크를 이미지 파일에 백업 할 때 차이 가 나는 경우는 무엇 입니까? 가 conv=sync,noerror법정 물건을 요구 사항은? 그렇다면 리눅스 페도라와 관련하여 왜 그런가?

편집하다:

좋아, 그래서 내가 dd없이 conv=sync,noerror, dd블록을 읽을 때 읽기 오류가 발생하면 (크기 100M), dd는 100M 블록을 건너 뛰고 무언가를 쓰지 않고 다음 블록을 읽습니다 ( dd conv=sync,noerror출력 100M에 0을 씁니다-그래서이 경우는 어떻습니까? ?)?

그리고 원본 하드 디스크의 해시와 출력 파일이 없으면 출력 파일이 다릅니 conv=sync,noerror까? 아니면 읽기 오류가 발생한 경우에만 해당됩니까?

conv=sync지시 dd자체는 이미지에 포함될 수있다하더라도 모든 데이터, 에러에 의한 전체 블록이 판독 될 수없는 경우이므로, 원래의 데이터의 전체 길이가 유지되어, 널 왼쪽에 패드에 각각의 블록을 . 그렇게하면 최소한 데이터의 손상 정도를 알고 법의학적인 단서를 제공 할 수 있으며 불량 블록 등으로 인해 이미지를 전혀 얻을 수없는 경우 데이터를 분석 할 수 없습니다. 일부는 없음보다 낫습니다.

conv=sync,noerrordd오류 발생시 중지 및 덤프 수행 을 방지하기 위해 필요합니다 . conv=sync틀림없이 큰 의미가 없습니다.

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

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

dd conv=sync,noerror(또는 conv=noerror,sync) 데이터가 손상되었습니다.

발생한 I / O 오류 및 사용 된 블록 크기 (물리적 섹터 크기보다 큼)에 따라 입력 및 출력 주소는 실제로 동기화되지 않고 잘못된 오프셋으로 끝나므로 파일 시스템 이미지 및 기타 파일에 사본을 사용할 수 없게됩니다. 오프셋이 중요한 것들.

conv=noerror,sync불량 디스크를 다룰 때 많은 곳에서 사용하는 것이 좋습니다 . 나는 같은 추천을했다. 얼마 전에 나쁜 디스크를 복구해야했을 때 그것은 효과가있었습니다.

그러나 테스트에 따르면 이것이 실제로는 전혀 신뢰할 수 없음을 나타냅니다.

사용 losetup및 dmsetup만드는 A error B장치 :

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

A, B 루프 장치는 다음과 같습니다.

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

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

따라서 A, B는 증가하는 숫자로 나중에 오프셋을 확인하는 데 도움이됩니다.

이제 리눅스 장치 매퍼에 의해 두 가지 사이에 읽기 오류가 발생합니다.

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

이 예는 생성 AerrorB과 2000섹터 A다음에, 2*48오류 섹터, 다음 2000섹터 B.

확인하기 위해 :

# 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

따라서 A127999\n각 줄에는 총 1024000 바이트 인 8 바이트가 있으며 이는 2000 섹터 인 512 바이트입니다. 모든 것이 정상인 것 같습니다 ...

혼합됩니까?

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

결과 :

# 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

파일 크기만으로도 일부 블록 크기에 문제가 있음을 알 수 있습니다.

체크섬 :

# 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

ddddrescue오류 영역 ( 512, 4K)에 맞춰지는 블록 크기에 대해서만 동의합니다 .

원시 데이터를 확인합시다.

# 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

데이터 자체가 존재하는 것처럼 보이지만 데이터는 동기화되지 않습니다. bs = 16K, 1M, 42,64K에 대한 오프셋이 완전히 깨졌습니다 2088576. 원래 장치에 대해 확인할 수 있듯이 오프셋 이 있는 오프셋 만 정확합니다.

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

이 예상되는 동작은 dd conv=noerror,sync? 나는 알지 못하고 dd사용 가능한 두 가지 구현은 서로 동의하지도 않습니다. dd퍼포먼스 블록 크기 선택과 함께 사용하면 결과는 매우 쓸모가 없습니다 .

상기를 이용하여 제조 하였다 dd (coreutils) 8.25, BusyBox v1.24.2, GNU ddrescue 1.21.