ddrescue очень медленный на жестком диске USB

Я восстанавливаю жесткий диск с моего ноутбука, который умер (не загружался вообще, Дисковая утилита сообщила, что проблем не было, но не смонтировала диск). Я подключил жесткий диск через USB-адаптер. Работает ddrescueтак:

sudo ddrescue -v -n /dev/disk1s2 "/Volumes/Original HD/image.dmg" ddrescue.log

Пока ошибок нет, но средняя скорость чтения постепенно упала до 50 КБ / с. Сначала было около 2 МБ / с. Размер раздела составляет 300 ГБ. До сих пор я смог восстановить 160 ГБ. Я восстанавливаюсь в раздел HFS + на моем MacBook.

Каковы могут быть причины такой медленной скорости передачи и как ее увеличить?

Казалось бы, именно так ddrescueи работает USB-передача под OSX. Из этой темы под названием: Тема: [Bug-ddrescue] ddrescue 10x замедляется под osx .

при работе на полностью функциональных жестких дисках под linux он выполняет полную скорость ввода-вывода. при компиляции под osx с флагами компиляции по умолчанию он в разы медленнее, иногда ползает до кбит / с. проблема сохраняется, если выходной файл / dev / null.

Та же самая тема также имела этот ответ.

По моему опыту и тестированию на OS X доступ к необработанным символьным устройствам /dev/rdisk…всегда предпочтительнее. Также скорость передачи может быть дополнительно увеличена путем установки большего размера блока копирования. Размер 512 КБ ( ddrescue -c 1Ki) дал мне лучшие результаты в большинстве случаев.

И: необработанные символьные устройства OS X имеют определенный размер, поэтому их легко использовать даже при первом запуске. (По крайней мере, в этом пункте примечания о необработанных устройствах в существующей документации ddrescueне относятся к OS X.)

Я не думаю, что это ошибка ddrescue, потому что другие утилиты любят ddили catдемонстрируют такое же поведение в OS X.

Доступ к блочному устройству / dev / disk… дает довольно медленную скорость, не зависящую от используемого размера блока копирования. С другой стороны, скорость чтения устройства / dev / rdisk… raw символ сильно зависит от выбранного размера блока копирования:

• 512 байт (по ddrescue -c 1умолчанию в dd) самый медленный.
• Установка его в 4096 байт ( ddrescue -c 8, dd bs=4K) дает такую ​​же медленную скорость, как и доступ к / dev / disk…
• по умолчанию ddrecue по 128 секторов (= по 64Kb, ddrescue -c 128, dd bs=64K) приносит неплохие результаты.
• Умножение, которое далее (до ddrescue -c 1Ki/ dd bs=512K) приносит максимальную скорость (в основном в 8-12 раз быстрее, чем /dev/disk…)
• Поднявшись выше, это не увеличило скорость передачи в моем тестировании; иногда даже уменьшается.

Это результаты моих собственных измерений, ваши результаты могут отличаться в зависимости от используемого носителя и оборудования ввода-вывода. Возможно, если бы некоторые другие пользователи поделились своим опытом, мы могли бы получить более полное представление о теме.

Ссылки

• ddrescue значительно замедлился на OS X
• GNU DDrescue, я делаю это правильно? [медленный / высокий размер ошибки]

Я не очень разбираюсь в HFS+файловой системе MacOS, однако я только что испытал, как восстановить внутренний жесткий диск объемом 500 ГБ (подключенный через SATA) на ноутбуке с Linux Mint с USB-накопителя, сохранив образ восстановления и файл журнала на exFatОтформатированный жесткий диск USB запускался довольно медленно (1-2 МБ / с), но после 250 ГБ он сканировал со скоростью <100 КБ / с. Казалось, что чем медленнее становился файл спасательного образа, тем медленнее он становился.

Затем я переместил образ восстановления и файл журнала в другое временное место, переформатировал жесткий диск USB с ext4файловой системой, переместил файлы обратно на него и возобновил процесс ddrescue - и теперь он снова работает с 1-20 МБ / с (колеблется но около 7 МБ / с в среднем)!

Похоже exFat, не очень хорошо играет с очень большими файлами (несколько сотен гигабайт). Как уже было сказано, я не знаю, так ли это на самом деле, HFS+но, может быть, вы хотите попробовать ext4.