Есть ли способ ускорить ddrescue?

Это может быть очень трудно увидеть прогресс ddrescue, но есть еще одна команда с именем ddrescuelog.

простая команда ddrescuelog -t YourLog.txt выведет эти славные infos:

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 работает...

Если ваша цель состоит в том, чтобы получить основную часть данных нетронутыми, то вы могли бы ускорить его извлечение. Но если вы действительно хотите, чтобы спасти как можно больше данных, как это возможно, то позволяя ddrecue грызть на каждом это маршрут, чтобы взять.

Я обнаружил, что играя с параметром-K вы можете все ускорить. Из того, что я видел, если ddrescue находит ошибку при запуске с опцией-n пытается перепрыгнуть фиксированное количество секторов. Если он все еще не может читать, он прыгает в два раза больше. Если у вас есть большие поврежденные области, вы можете указать большое значение K (например, 100 м), и поэтому прыжок на ошибку будет больше в первый раз, и будет легче избежать проблемных областей быстро в первом прошлом.

кстати, есть замечательное графическое приложение для анализа лога.

http://sourceforge.net/projects/ddrescueview/

еще один способ мониторинга прогресса 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, "01653733o7M652101653733o7M6521"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET)       = 1702220261376
read(3, "01653733o7M652101653733o7M6521"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET)       = 1702220261376
write(4, "01653733o7M652101653733o7M6521"..., 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 для процессорного времени. Я взял, чтобы трубопровод его "голову", так что я могу захватить первые 10 значений:

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

надеюсь, это кому-то поможет.

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

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

кажется exFat не очень хорошо играть с очень большими файлами (несколько сотен гигабайт).