Вопросы Теги

Пакетная обработка картографического файла ddrescue с отладками

Мне нужно было сделать это на VPS, и ни одно из предложенных решений не помогло,

этот ответ помог

https://serverfault.com/questions/551453/how-do-i-verify-that-my-hosting-provider-gave-me-ssds/551495#551495

Итак, речь идет о чтении случайных данных с диска и оценке времени. 

time for i in `seq 1 1000`; do
    dd bs=4k if=/dev/sda count=1 skip=$(( $RANDOM * 128 )) >/dev/null 2>&1;
done

вот мои результаты для SSD

real    0m1.375s
user    0m0.285s
sys     0m0.944s

и HDD

real    0m14.249s
user    0m0.752s
sys     0m6.284s

1
06.10.2018, 09:52
2 ответа

Кажется, я нашел решение своей проблемы. Тем не менее, мне все еще любопытно, может ли кто-нибудь придумать более элегантное решение или, возможно, найти ошибку в моем решении.

Как оказалось, я мог записать на стандартный ввод debugfs, поэтому мне нужно было только сгенерировать последовательность команд для debugfsи проанализировать вывод ddrescue.

Следующий сценарий bash предполагает, что файл с именем mapfile.ddrescueприсутствует в текущем каталоге, созданном ddrescue. 

for line in \
    $(cat mapfile.ddrescue | \
      grep -e "-$" | \
      awk -F" " '{print $1}' | \
      awk -F"0x" '{print $2}'); \
do \
    position=$(( 16#$line / 512 - 91914240 )); \
    result="$result $position"; \
done; \
echo -e "open /dev/sdd3\nicheck $result\nquit\n" | sudo debugfs

Вот что делает этот скрипт:

  1. Я анализирую mapfileиз ddrescue, который я назвал mapfile.ddrescue.
  2. Я фильтрую его, чтобы оставить только строки, которые заканчиваются дефисом. Это позиции с плохими блоками.
  3. Я использую awk для разделения по пробелам и печати первой лексемы, которая является позицией. Он будет содержать шестнадцатеричное число, например 0x34A933F000.
  4. Я удаляю префикс Ox.
  5. Результат, возвращаемый вызовом $(...), служит входом для цикла for -, поэтому строка всегда будет содержать одну позицию.
  6. Я использую выражение $((... ))для математических вычислений позиции, делю позицию на 512 (, например. байт на сектор )и вычесть начало раздела, которое в моем случае равно 91914240. Это дает позицию в секторах относительно начала раздела.
  7. Я объединяю каждую позицию в список, разделенный пробелами, который хранится в $result.
  8. Наконец, я генерирую список команд, разделенных новой строкой -, который передаю на стандартный ввод команды debugfs, которую запускаю с помощью sudo. Команда открывает устройство (в моем случае /dev/sdd3). Затем он запускается icheckна $resultи завершает работу на debugfs.

Когда я запустил этот скрипт, debugfsпотребовалось много времени, чтобы найти все inodesдля этих блоков, в моем случае он зависал несколько минут, пока не напечатал вывод.

Когда сценарий завершился, я скопировал результат в текстовый файл и проанализировал его. К счастью, большинство секторов указывало на нераспределенные блоки, а остальные указывали на одни и те же несколько inodeномеров. После удаления строк с <block not found>и удаления дубликатов осталось только четыре inodes, которые я мог вручную проверить с debugfsс помощью ncheck. Это дало мне четыре пути к файлам, это файлы, которые я сейчас попытаюсь восстановить из резервной копии.

Фон Первоначально я начал с ddи хотел скопировать содержимое SSD на 256 ГБ на SSD большего размера. ddпрервано из-за ошибок ввода-вывода примерно на 45/185 ГБ последнего раздела. Однако с помощью ddrescueя смог сэкономить 99,99% диска. Наконец, с помощью приведенного выше решения я смог проверить, к каким файлам относятся оставшиеся 1700 КБ или 418 поврежденных областей, и нашел только четыре файла, которые повреждены. Это значительно повысило мое доверие к восстановленным данным, поскольку теперь я знаю, какие файлы повреждены, и могу восстановить их из старой резервной копии.

0
27.01.2020, 23:42

Мне пришлось сделать это сегодня после того, как моя SD-карта rpi3b+ умерла. В итоге я написал скрипт на python, делающий то же, что вы делали в своем скрипте bash выше, за исключением того, что он автоматически выдает пути к файлам. Посмотреть можно здесь:https://github.com/zkrx/rescue2path

В этом решении я также проверяю наличие -еще не -очищенных фрагментов данных ('/' ). Скрапинг здесь занял очень много времени, и я просто остановился, не успев завершить его.

Эта запись в Arch wiki оказалась особенно полезной:https://wiki.archlinux.org/index.php/Identify_damaged_files

1
27.01.2020, 23:42

Теги

Похожие вопросы