Где-то в интернете я читал, что gddrescue превосходит dd, по крайней мере, с точки зрения способности различать количество операций чтения с диска, выполненных в проблемном секторе. Это действительно так?
время dd if = / dev / sda skip = 900343967 of = a.bin count = 4 iflag = direct conv = noerror, sync
дд: чтение `/ 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 MB, ошибки: 1, средняя скорость: 53 B / s,
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 (использовать синхронную запись для выходного файла)? Я не заметил никакой разницы с некоторыми из проведенных испытаний.
Кто-нибудь может прокомментировать все это? Спасибо.
В зависимости от того, когда был изготовлен жесткий диск, а также от производителя и какой версии микропрограммы он работает, с современными жесткими дисками, когда обнаруживаются плохие сектора, они удаляются из микропрограммы, и накопитель знает, как пропустить поврежденные сектора. Таким образом, понятие «спасение» жесткого диска от плохих секторов может быть спорным в этом отношении. Вопрос о том, имели ли теперь плохие секторы когда-то действительные данные, является подходящим решением, которое вы ищете - без каламбура!
На grc.com есть программное обеспечение spinrite 6, которое утверждает, что может исправлять жесткие диски с поврежденными секторами. Это платное программное обеспечение, и я никогда не пробовал его. Об этом стоит прочитать, особенно если кто-то пытается «воскресить» жесткий диск, и он действительно работает, как описано. FAQ на grc.com относительно spinrite 6 указывает на то, что существует 30-дневная гарантия возврата денег (и нет пробной или бесплатной версии). Примечание: я не связан с grc.com и не рекомендую его для вашей ситуации. Я просто знаю, что он существует и может работать как рекламируется, но не верьте мне на слово - будьте бдительны.
Что касается оценки того, превосходит ли gddrescue «dd», по крайней мере, с точки зрения способности различать количество операций чтения с диска, выполненных в проблемном секторе, любое количество операций чтения в поврежденном секторе (поскольку оно помечено как не Мне кажется, что функциональный сектор в списке поврежденных секторов, хранящихся в списке встроенного ПО) не будет полезен при качественном использовании gddrescue или dd.
Может оказаться полезным прочитать веб-страницу dd (Unix) по адресу: https://secure.wikimedia.org/wikipedia/en/wiki/Gddrescue#Recovery-oriented_variants_of_dd.
Вам также может быть полезно взглянуть на: Как создать образ поврежденного жесткого диска с помощью UBCD, dd-rescue и P2 eXplorer по адресу: http://www.myfixlog.com/fix.php?fid= 21
источник