Что делает dd conv=sync, noerror?

так что же происходит при добавлении conv=sync,noerror разница при резервном копировании всего жесткого диска в файл изображения? Это conv=sync,noerror требование при выполнении судебно вещи? Если да, то почему это так со ссылкой на Linux fedora?

Edit:

хорошо, если я делаю dd без conv=sync,noerror и dd встречает ошибку чтения при чтении блока (давайте размер 100M), DD просто пропускает блок 100M и читает следующий блок, не записывая что-то (dd conv=sync,noerror пишет нулей 100M выхода - так как насчет этого случая?)?

и если хэш исходного жесткого диска и выходного файла отличается, если сделано без conv=sync,noerror? Или это только тогда, когда произошла ошибка чтения?

5
задан Roney Michael
30.01.2023 19:37 Количество просмотров материала 2777
Распечатать страницу

2 ответа

conv=sync говорит dd для заполнения каждого блока слева значениями null, так что если из-за ошибки полный блок не может быть прочитан, сохраняется полная длина исходных данных, даже если не все данные могут быть включены в изображение. таким образом, вы по крайней мере знаете, как поврежденные данные, которые может предоставить вам улики, и если вы не можете взять изображение из-за плохих блоков или любой другой, вы не можете анализировать любые данные. некоторые лучше, чем никто.

conv=sync,noerror нужно запретить dd от остановки по ошибке и выполнения дампа. conv=sync в значительной степени лишено смысла нет.

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

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

35
отвечен Frank Thomas 2023-02-01 03:25

dd conv=sync,noerror (или conv=noerror,sync) портит ваши данные.

в зависимости от возникшей ошибки ввода / вывода и используемого размера блока (больше размера физического сектора?), адреса ввода и вывода на самом деле не синхронизируются, но в конечном итоге имеют неправильные смещения, что делает копию бесполезной для образов файловой системы и других вещей, где смещения имеют значение.

многие места рекомендуют использовать 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 с увеличивающимися числами, которые помогут нам проверить смещения позже.

теперь, чтобы поместить ошибку чтения между ними, любезно Linux устройство отображения:

# 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, поскольку каждая строка имеет 8 байт, что составляет 1024000 байт, наши 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

только из размеров файлов вы можете сказать, что что-то не так для некоторых blocksizes.

контрольные суммы:

# 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 договаривается с ddrescue только для размеров блоков, которые выровнены по нашей зоне ошибок (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, 64 K... только те со смещением 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.

27
отвечен frostschutz 2023-02-01 05:42

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя

Похожие вопросы про тегам:

backup
dd
forensics
linux
Вверх