У меня сломался жесткий диск на 500 ГБ примерно 5 дней назад. Я использовал ddrescueважный раздел несколько дней назад, и он находится в состоянии «Обрезка неисправных блоков» уже почти 2 дня.
Исходная команда:
ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log
Выходной ток:
Initial status (read from logfile)
rescued: 248992 MB, errsize: 1007 MB, errors: 15867
Current status
rescued: 249021 MB, errsize: 978 MB, current rate: 17408 B/s
ipos: 44405 MB, errors: 15866, average rate: 2784 B/s
opos: 44405 MB, time from last successful read: 0 s
Trimming failed blocks...
Первоначальная команда использовала этот ddrescue -nпараметр, и я перезапускал процесс несколько раз по мере необходимости (и каждый раз он возобновлялся с того места, на котором остановился).
Есть ли способ ускорить этот процесс?
Редактировать:Шесть часов спустя текущий статус выглядит следующим образом:
rescued: 249079 MB, errsize: 920 MB, current rate: 409 B/s
ipos: 39908 MB, errors: 15851, average rate: 2698 B/s
opos: 39908 MB, time from last successful read: 0 s
Trimming failed blocks...
Похоже, что пока "errors" отсчитывает мучительно медленно, ipos/opos отсчитывает, сколько данных ему нужно обработать, и, похоже, он работает со скоростью 750 МБ/час. При такой скорости он завершит работу примерно за 53 часа. Ужас.
Редактирование №2:Два дня спустя, все еще работает. Однако есть надежда. Он прошел часть «Обрезка неисправных блоков» и перешел к следующей фазе «Разделение неисправных блоков». Если что, то из того, что следует вынести из просмотра этого вопроса, это то, что это определенно занимает много времени, когда задействовано большое количество данных/ошибок. Моя единственная надежда в том, что я смогу успешно восстановить некоторые важные данные, когда все будет сказано и сделано.
rescued: 249311 MB, errsize: 688 MB, current rate: 0 B/s
ipos: 26727 MB, errors: 15905, average rate: 1331 B/s
opos: 26727 MB, time from last successful read: 20 s
Splitting failed blocks...
решение1
Я заметил, что использование -nопции (без разделения) вместе с опцией -r 1(повторить попытку один раз) и установкой -cменьшего значения (размер кластера) может помочь.
У меня сложилось впечатление, что шаг разделения очень медленный, так как ddrescueон разделяет и снова разделяет поврежденные области. Это занимает много времени, поскольку ddrescueпытается восстановить очень маленькие порции данных. Поэтому я предпочитаю использовать -n(no-split) вместе с -c 64, -c 32, -c 16, а также
Вероятно, -n(no-split) всегда следует использовать для одного первого прохода в прямом и обратном направлениях. Кажется, чем больше данные были разделены, тем медленнее клонирование, хотя я в этом не уверен. Я предполагаю, что чем больше необработанные области, тем лучше при ddrescueповторном запуске, потому что больше смежных секторов нужно клонировать.
Поскольку я использую файл журнала, я не задумываясь отменяю команду с помощью Ctrl+ C, когда скорость чтения данных становится в два раза ниже.
Я также использую -Rрежим (Обратный), и после первого прохода он часто обеспечивает более высокую скорость чтения назад, чем вперед.
Мне не ясно, как -r Nобрабатываются уже повторенные сектора ( ) при ddrescueповторном запуске команды, особенно при чередовании прямых (по умолчанию) и обратных ( -R) команд клонирования. Я не уверен, сохраняется ли количество попыток в файле журнала, и, вероятно, работа выполняется снова бесполезно.
Вероятно, -iфлаг (позиция ввода) также может помочь ускорить процесс.
решение2
Прогресс выполнения может быть очень трудно увидеть ddrescue, но есть еще одна команда, которая называется ddrescuelog.
Простая команда ddrescuelog -t YourLog.txtвыведет следующую полезную информацию:
current pos: 2016 GB, current status: trimming
domain size: 3000 GB, in 1 area(s)
rescued: 2998 GB, in 12802 area(s) ( 99.91%)
non-tried: 0 B, in 0 area(s) ( 0%)
errsize: 2452 MB, errors: 12801 ( 0.08%)
non-trimmed: 178896 kB, in 3395 area(s) ( 0.00%)
non-split: 2262 MB, in 9803 area(s) ( 0.07%)
bad-sector: 10451 kB, in 19613 area(s) ( 0.00%)
Вы даже можете использовать его во время ddrescueработы...
решение3
Я обнаружил, что играя с параметром -K, можно ускорить процесс. Из того, что я видел, если ddrescue находит ошибку при запуске с параметром -n, он пытается перейти на фиксированное количество секторов. Если он все еще не может прочитать, он переходит на двойной размер. Если у вас большие поврежденные области, вы можете указать большое значение K (например, 100M), и тогда переход при ошибке будет больше в первый раз, и будет легче быстро избегать проблемных областей в первом прошлом.
Кстати, есть замечательное графическое приложение для анализа лога.
решение4
Еще один способ отслеживать ход выполнения ddrescue (по крайней мере, в Linux) — использовать strace.
Сначала найдите PID процесса ddrescue с помощью «ps aux | grep ddrescue»
root@mojo:~# ps aux | grep ddrescue
root 12083 0.2 0.0 15764 3248 pts/1 D+ 17:15 0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root 12637 0.0 0.0 13588 940 pts/4 S+ 17:46 0:00 grep --color=auto ddrescue
Затем запустите "strace" для этого процесса. Вы увидите что-то вроде:
root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET) = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET) = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET) = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C
...и так далее. Вывод быстрый и некрасивый, поэтому я пропускаю его через "grep", чтобы отфильтровать то, что мне интересно:
root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET) = 1702212679168
lseek(3, 1702212678656, SEEK_SET) = 1702212678656
lseek(4, 1702212678656, SEEK_SET) = 1702212678656
lseek(3, 1702212678144, SEEK_SET) = 1702212678144
lseek(4, 1702212678144, SEEK_SET) = 1702212678144
lseek(3, 1702212677632, SEEK_SET) = 1702212677632
lseek(4, 1702212677632, SEEK_SET) = 1702212677632
lseek(3, 1702212677120, SEEK_SET) = 1702212677120
lseek(4, 1702212677120, SEEK_SET) = 1702212677120
lseek(3, 1702212676608, SEEK_SET) = 1702212676608
^C
В этом примере «1702212676608» соответствует «объему данных, которые еще необходимо обработать на том 2-терабайтном диске, который вы пытаетесь спасти». (Да. Ой.) ddrescue выдает похожее число — хотя и «1720 ГБ» — на своем экране.
strace предоставляет вам поток данных с НАМНОГО более высокой степенью детализации для изучения; это еще один способ оценить скорость работы ddrescue и приблизительно определить дату завершения.
Запускать его постоянно, вероятно, плохой план, поскольку он будет конкурировать с ddrescue за процессорное время. Я перенаправляю его в "head", чтобы иметь возможность получить первые 10 значений:
root@mojo:~# strace -p 4073 2>&1 | grep lseek | head
Надеюсь, это кому-то поможет.