DDrescue параллельная операция

514
Ro-ee

Я использую ddrescue для восстановления данных с диска Seagate Barracuda 3TB. Диск выходит из строя, но до сих пор каждый сектор, который я пытаюсь прочитать, в конечном итоге возвращает правильные данные, но это может потребовать некоторого исследования (это означает, что ddrescue должен выполнить несколько проходов на последнем этапе, где считываются поврежденные сектора).

Нормальная работа очень медленная, хотя. У меня есть некоторые участки на диске, которые читаются на полной скорости (60 МБ / с), но после успешного получения ~ 2,5 ТБ данных оставшиеся 500 ГБ распределяются по всему диску и читаются с головокружительной скоростью ~ 2 КБ / с. с оценкой несколько тысяч дней, чтобы закончить.

Однако я могу одновременно запустить несколько экземпляров ddrescue на одном диске, что увеличивает пропускную способность, но я не уверен, как в конечном итоге объединить данные в одно изображение, особенно путем отслеживания с файлом карты. Я предполагаю, что несколько процессов означают несколько файлов карт.

Кроме того, кто-нибудь знает, почему диск так медленно? Я имею в виду, что 2 КБ / с (или меньше, в случае ошибок) кропотливо медленны, возвращает воспоминания о C64. Мне потребовалось 3 часа, чтобы получить 30 МБ данных. У меня был бы идентичный диск Barracuda 3TB, который мог бы функционировать в качестве донора органов, если бы случайно смена контроллера смогла бы смягчить проблему (но, читая об этом, сомнительно, что это сработает).

1
Действительно ли запуск нескольких экземпляров увеличивает пропускную способность? Или это просто кажется быстрее, так как медленные чтения затеняются более быстрыми чтениями? Мне трудно представить себе случай, когда наличие нескольких считывателей на одном вращающемся диске приведет к более высокой скорости чтения? Кажется, вы бы на самом деле замедлили ход событий, добавив больше поиска головы? ernie 6 лет назад 0
Мне придется проверить это, но я не уверен, что диск делает много движений головы, когда читает только со скоростью 2 КБ / с. Конечно, если это происходит из-за необходимости часто перечитывать сектор внутри, это может иметь место, и поиск в других местах ухудшил бы скорость ... Ro-ee 6 лет назад 0
Да, я имею в виду даже с отлично работающим диском, я не знаю, как два одновременных чтения могут быть быстрее, чем один читатель. ernie 6 лет назад 0
Если (и это очень важно, если) медленная скорость чтения вызвана не самим чтением, а чем-то другим в дисководе (помните, что диск вот-вот выйдет из строя, умные данные вызывают у меня дрожь), тогда одновременное чтение может быть быстрее, поскольку физическое чтение / само по себе / будет выполняться за то же время, но остальная обработка данных займет остальное время. Это единственная причина, по которой я могу придумать, но тесты должны это показать. Я знаю, что когда я ограничиваю размер с помощью ddrescue 30 МБ, это занимает около 3 часов. Таким образом, я могу сделать это параллельно и посмотреть, что это займет 3 или 6 часов .. Ro-ee 6 лет назад 0
Одновременное чтение всегда приводит к поиску головы, замедляя процесс. Кажется, вы представляете себе сценарий, где узким местом является то, что он читает что-то с диска, а затем происходит некоторая обработка или что-то очень медленное, и это узкое место? Это кажется очень, очень маловероятным. С неисправным диском я бы очень неохотно делал параллельные считыватели, так как вы вносите дополнительный износ в дисковод с дополнительными головками. Вместо того, чтобы использовать dd или подобное, я мог бы просто попытаться скопировать файлы, которые мне абсолютно необходимы. ernie 6 лет назад 0
Как насчет уловки smartctl из этого ответа (https://superuser.com/a/905814/432690)? Kamil Maciorowski 6 лет назад 0
@Kamil Maciorowski: к сожалению, smartctl возвращает сообщение «Команда SCT Error Recovery Control не поддерживается». Ro-ee 6 лет назад 0
@ernie, параллельное чтение не улучшает скорость, как показали мои измерения (к сожалению). Ro-ee 6 лет назад 0

1 ответ на вопрос

0
Deltik

Вместо того, чтобы усложнять ситуацию с двумя изображениями, вы можете указать GNU ddrescue пропустить медленные части и вернуться к ним позже.

Флаг, который позволяет вам сделать это --min-read-bytes=.

Из руководства по спасению GNU :

--min-read-rate=bytes

Минимальная скорость чтения хороших непробованных областей, в байтах в секунду. Если скорость чтения падает ниже этого значения, ddrescue пропустит переменную величину в зависимости от скорости и истории ошибок. Пропущенные блоки пробуются в дополнительных проходах (до обрезки). Если число байтов равно 0 (авто), минимальная скорость чтения пересчитывается каждую секунду как (average_rate / 10).


Если вы настаиваете на создании нескольких изображений, в руководстве также есть пример того, как их объединить:

Пример 4: объединить частично восстановленные образы 3-х одинаковых DVD-дисков, используя их файлы карт в качестве файлов файлов карты домена.

 ddrescue -m mapfile1 dvdimage1 dvdimage mapfile ddrescue -m mapfile2 dvdimage2 dvdimage mapfile ddrescue -m mapfile3 dvdimage3 dvdimage mapfile (if bad-sector size is zero, dvdimage now contains a complete image of the DVD and you can write it to a blank DVD) 
Я уже использую -a (= --min-read-bytes), который выдает на уровне 20000 байт / с. Я выполняю его несколько раз на проходе 1 (я поиграл со сбросом «текущего» указателя в файле карты, так как обнаружил, что пропущены еще большие отрезки, что до сих пор помогло мне получить ~ 10 ГБ дополнительных данных в последнем часов. Но в конечном итоге все большие области будут обработаны, и у меня останется 30 МБ непробованных областей, к северу от 50 000. Спасибо за совет по слиянию. Ro-ee 6 лет назад 0