Где-то в интернете я читал, что gddrescue превосходит dd, по крайней мере, с точки зрения способности различать количество операций чтения с диска, выполненных в проблемном секторе. Это действительно так?
время dd if =/dev/sda skip = 900343967 of = a.bin count = 4 iflag = direct conv = noerror, sync
dd: чтение `/dev/sda ': ошибка ввода / вывода
2+0 записей в
2+0 записей
Скопировано 1024 байта (1,0 кБ), 18,6057 с, 0,1 кБ / с
3+1 записей в
4+0 записей
Скопировано 2048 байт (2,0 кБ), 18,6707 с, 0,1 кБ / среальный 0m18.672s
пользователь 0m0.000s
sys 0m0.004s
Кстати, прямой флаг действительно помогает, без него я смог прочитать только 1 сектор из 4 (против 3/4 с ним). Тем не менее, это заметно замедляет скорость передачи - для меня она, по крайней мере, примерно в 5 раз медленнее: 5 МБ / с против 25 МБ / с без этого флага. Во всяком случае, теперь для gddrescue (ddrescue) часть ..
время ddrescue -b512 -c1 -s4b -dnvD -i900343967b -o0b /dev /sda b.bin
Собирается скопировать 2048 байт из /dev /sda в b.bin
Исходные позиции: infile = 460976 МБ, outfile = 0 B
Размер блока копирования: 1 жесткий блок
Размер жесткого блока: 512 байт
Max_retries: 0
Прямая: да Разреженная: нет Разделенная: нет Усеченная: нетНажмите Ctrl-C, чтобы прервать
спасено: 1536 B, ошибка: 512 B, текущая скорость: 53 B /s
IPOS: 460976 МБ, ошибки: 1, средняя скорость: 53 Б / с.
opos: 1536 B, время от последнего успешного чтения: 0 с
Законченныйреальный 0m18.736s
пользователь 0m0.004s
sys 0m0.000s
Как показано выше, для выполнения потребовалось столько же времени. Как и ожидалось - такая же статистика: 3/4. Тем не менее, хотя я могу дополнить проблемные секторы 0x00 для dd (conv = sync), gddrescue, похоже, не хватает этой функциональности? Вместо этого он просто пропускает проблемный сектор без записи чего-либо на свою позицию и переходит к следующему следующему сектору (если у меня уже есть данные, записанные по этому сектору в выходном файле - это не будет перезаписано: иногда это может быть нежелательно) ). Я не уверен, как опция -t (truncate) будет работать для блочного устройства с gddrescue (я думаю, он полностью перезапишет его с 0x00), но в обычном файле он, как и предполагалось, усекает весь файл без этого только в пределах размеров смещения (т.е. -o1). Таким образом, это немного похоже на синхронизацию dd , но далеко не то же самое, что будет имитировать только идентичность функциональности, если вы готовы перезаписать все устройство вывода / файл.
Хотя, благодаря наличию подробной опции и возможности регистрировать поврежденные сектора / блоки, gddrescue кажется лучшим выбором. Важно отметить, что оба приложения были запущены с (в значительной степени) одинаковыми параметрами.
Выход из
diff?.bin
пусто (выход 0), то есть файлы точно такие же.
Теперь это часть, которую я не понимаю
dd работает медленно даже без ошибок, так как он выполняет крошечные операции чтения и записи. Он тратит много времени на пережевывание ошибочных частей диска, вместо того, чтобы читать как можно больше безошибочных материалов, а затем вернуться к выполнению сложных задач.
Что это вообще такое? Особенно часть « она тратит много времени на пережевывание ошибочных частей диска, а не на чтение как можно большего количества безошибочных вещей, ТО, ЧТО потом возвращаешься к трудным вещам »? Это заняло столько же времени, как показано выше (хотя я проверил очень маленькую порцию данных, но должно ли это иметь значение?).
gddrescue предлагает ключ -r , который должен контролировать количество повторных считываний в "плохом секторе", однако, dd, кажется, все время работает с -r0 (так как это заняло то же время). Итак, эта опция просто для "постобработки"? Я имею в виду , что изначально и dd, и gddrescue, кажется, работают с -r0, и dd , похоже, не пережевывает ошибочные части, как gddrescue (кажется, что оба они останавливаются на плохом блоке на 15-18 секунды дают или берут, так в чем же дело, как быстрее работает gddrescue ???)
Кроме того, для чего нужна опция -D (использовать синхронную запись для выходного файла)? Я не заметил никакой разницы с некоторыми из проведенных испытаний.
Кто-нибудь может прокомментировать все это? Благодарю.