Do czego służy dd conv = sync, noerror?

Więc co się dzieje, gdy dodanie conv=sync,noerrorrobi różnicę podczas tworzenia kopii zapasowej całego dysku twardego w pliku obrazu? Czy conv=sync,noerrorjest wymagane przy wykonywaniu czynności kryminalistycznych? Jeśli tak, to dlaczego tak jest w przypadku linux fedora?

Edytować:

OK, więc jeśli wykonam dd bez conv=sync,noerrori ddnapotka błąd odczytu podczas odczytu bloku (zmieńmy rozmiar 100M), dd po prostu pominie blok 100M i odczyta następny blok bez zapisywania czegoś ( dd conv=sync,noerrorzapisuje zera na 100M wyniku - więc co z tym przypadkiem ?)

A jeśli skróty oryginalnego dysku twardego i pliku wyjściowego są inne, jeśli są wykonywane bez conv=sync,noerror? Czy to tylko wtedy, gdy wystąpił błąd odczytu?

conv=syncnakazuje ddwstawienie każdego bloku w lewo wartościami null, aby jeśli z powodu błędu nie można odczytać pełnego bloku, zachowana jest pełna długość oryginalnych danych, nawet jeśli nie wszystkie dane mogą być zawarte w obrazie . w ten sposób wiesz przynajmniej, jak uszkodzone są dane, co może dostarczyć ci wskazówek kryminalistycznych, a jeśli nie możesz w ogóle zrobić zdjęcia z powodu złych bloków lub cokolwiek innego, nie możesz analizować żadnych danych. niektóre są lepsze niż żadne.

conv=sync,noerrorjest konieczne, aby zapobiec ddzatrzymaniu po błędzie i wykonaniu zrzutu. conv=syncjest w dużej mierze bez znaczenia bez żadnych przeszkód.

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

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

dd conv=sync,noerror(lub conv=noerror,sync) powoduje uszkodzenie danych.

W zależności od napotkanego błędu we / wy i zastosowanego rozmiaru bloku (większy niż rozmiar sektora fizycznego?) Adresy wejściowe i wyjściowe nie są właściwie zsynchronizowane, ale kończą się nieprawidłowymi przesunięciami, co czyni kopię bezużyteczną dla obrazów systemu plików i innych rzeczy, w których znaczenie mają przesunięcia.

Wiele miejsc zaleca korzystanie conv=noerror,syncz niewłaściwych dysków. Sam dawałem takie same rekomendacje. To zadziałało, kiedy jakiś czas temu musiałem odzyskać zły dysk.

Testy sugerują jednak, że tak naprawdę nie jest to wcale wiarygodne.

Użyj losetupi, dmsetupaby utworzyć A error Burządzenie:

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

Urządzenia z pętlą A, B wyglądają tak:

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

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

Więc to A, B z rosnącymi liczbami, które pomogą nam później zweryfikować przesunięcia.

Teraz, aby umieścić błąd odczytu pomiędzy tymi dwoma, dzięki uprzejmości mapera urządzeń Linux:

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

Ten przykład tworzy AerrorBjak w 2000sektorach A, a następnie 2*48sektorów błędu, a następnie 2000sektorówB .

Aby zweryfikować:

# 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

Czyta do A127999\n, ponieważ każda linia ma 8 bajtów, co daje 1024 000 bajtów, czyli 2000 sektorów 512 bajtów. Wszystko wydaje się być w porządku ...

Czy to się zmiksuje?

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

Wyniki:

# 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

Na podstawie samych rozmiarów plików można stwierdzić, że niektóre wielkości bloków są nieprawidłowe.

Sumy kontrolne:

# 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

ddzgadza się ddrescuetylko z rozmiarami bloków, które akurat są dostosowane do naszej strefy błędów ( 512, 4K).

Sprawdźmy surowe dane.

# 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

Chociaż same dane wydają się być obecne, oczywiście nie są zsynchronizowane; przesunięcia są całkowicie nie do zniesienia dla bs = 16K, 1M, 42,64K ... tylko te z przesunięciem 2088576są poprawne, co można zweryfikować na oryginalnym urządzeniu.

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

Czy to oczekiwane zachowanie dd conv=noerror,sync? Nie wiem, a dwie implementacje, ddktóre miałem dostępne, nawet się ze sobą nie zgadzają. Rezultat jest bardzo bezużyteczny, jeśli użyjesz ddwydajnego wyboru rozmiaru bloku.

Powyższy wytworzono stosując dd (coreutils) 8.25, BusyBox v1.24.2, GNU ddrescue 1.21.