ddrescue надзвичайно повільно на жорсткому диску USB

Я відновлюю жорсткий диск зі свого померлого ноутбука (не завантажувався б зовсім, Disk Utility повідомив, що проблем не було, але диск не змогли встановити). Я підключив жорсткий диск через 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 з прапорами компіляції за замовчуванням, це на величину в рази повільніше, іноді сканує до Kb / s. проблема зберігається, якщо вихідний файл / dev / null.

Ця ж нитка мала і цю відповідь.

З мого досвіду та тестування на ОС X, доступ до пристроїв із необробленими символами /dev/rdisk…завжди є кращим. Також можна збільшити швидкість передачі, встановивши більший розмір блоку копіювання. Розмір 512KiB ( ddrescue -c 1Ki) дав мені найкращі результати у більшості випадків.

І: пристрої для необроблених символів OS X мають визначений розмір, тому їх можна легко використовувати навіть у першому запуску. (Принаймні, в цьому пункті примітки про необроблені пристрої в існуючій документації на ddrescueне поширюються на ОС X.)

Я не думаю, що це помилка ddrescue, оскільки інші утиліти люблять ddабо catдемонструють таку саму поведінку в OS X.

Доступ до блоку / dev / disk… забезпечує досить повільну швидкість, незалежно від використовуваного розміру блоку копіювання. Швидкість читання a / dev / rdisk… пристрою необробленого символу з іншого боку багато в чому залежить від обраного розміру блоку копіювання:

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

Це результати моїх власних вимірювань, ваші результати можуть відрізнятися залежно від засобів масової інформації та обладнання IO, що використовується. Можливо, якщо деякі інші користувачі поділяться своїм досвідом, ми могли б отримати кращу картину теми.

Список літератури

• 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постріл.