Чтобы сделать этот ответ хотя бы частично полезным для других пользователей с похожими проблемами, давайте процитируем ключевые части вашего журнала здесь:
# Rescue Logfile. Created by GNU ddrescue version 1.18.1
# Command line: ddrescue -f -d -R -r3 /dev/sde /dev/sdf /mnt/somedir/logfiles/log3.log
# Start time: 2017-08-14 10:22:44
# Current time: 2017-08-14 12:13:09
# Copying non-tried blocks... Pass 1 (backwards)
# current_pos current_status
0x27BF0520000 ?
# pos size status
0x00000000 0x02870000 +
0x02870000 0x001A0000 *
0x02A10000 0x00010200 +
0x02A20200 0x0005FE00 *
# ... many lines here
0x2BA92360000 0x00040000 ?
0x2BA923A0000 0x00010000 *
# binary garbage here
0xE4E1710000 0x00010000 *
# ... many lines here
0x13D75970000 0x00000200 +
0x13D75970200 0x00
Вы определили строку как раз перед двоичным мусором, чтобы быть последним допустимым. Там написано 0x2BA923A0000 0x00010000 * и это номер строки 880829 в вашем случае. Это имеет смысл, потому что строки после мусора имеют более низкие позиции (первые числа), они, кажется, дублируют более ранние строки.
я сделал
<log3.txt head -n 880829 > log3new.txt
и запустите ddrescue ( поскольку infile является зацикленным устройством из большого разреженного файла, это не должно иметь значения). Жаловался на линию 583658.
Это линия с ее окрестностями:
# ...
0x186C6940000 0x00000200 +
0x186C6940200 A9520200 0x0001FE00 * # <- this line here
0x24AA9540000 0x00000200 +
# ...
Чтобы это исправить, вы должны охватить весь диапазон от 0x186C6940200 до 0x24AA9540000 , поэтому лог-файл является непрерывным. Длина составляет 0x24AA9540000 - 0x186C6940200 = 0xC3E2BFFE00 . Вся строка 583658 должна быть:
0x186C6940200 0xC3E2BFFE00 ?
где ? означает непробованные блоки.
Я исправил
sed -i '583658s/.*/0x186C6940200 0xC3E2BFFE00 ?/' log3new.txt
Полученный файл журнала действителен для ddrescue .
РЕДАКТИРОВАТЬ
Однако проблема, с которой я столкнулся, заключается в том, что он заставляет DDrescue думать, что он восстановил только 2041 ГБ, а когда произошел сбой, он был выше 2800 ГБ, и, как вы можете себе представить, эти последние 800 ГБ заняли много недель, чтобы их восстановить.
На самом деле мы не знаем, те же самые 800 ГБ. Есть инструмент ddrescueview (с графическим интерфейсом, доступный как пакет ddrescueview в Ubuntu), который покажет вам, где именно эти неиспробованные блоки, которые мы ввели. Обратите внимание, что текущая позиция находится в другом месте:
Поэтому мне интересно, может ли информация, связанная с мусором, иметь к этому отношение? В любом случае мы можем включить его в файл журнала?
Я выделил эту часть "после мусора", последние 129289 строк:
tail -n 129289 log3.txt > extra.txt
Эта команда покажет вам строки, которые находятся в extra.txt но не в log3new.txt:
diff --suppress-common-lines extra.txt log3new.txt | grep -e '^<'
Выход
< 0x13D75970200 0x00
Это означает, что только последняя (неполная) строка после мусора не находится перед мусором в оригинальном log3.txt . Извините, мне кажется, log3new.txt - это лучшее, что вы можете получить.
