17

У меня есть вопрос, касающийся неисправимых ошибок в файловой системе BTRFS. В частности, я недавно запустил BTRFS Scrub после того, как у меня возникла проблема с одной из моих флешек RAM, и, похоже, обнаружены 4 неисправимые ошибки. Это вывод:

scrub status for <UUID>
    scrub started at Thu Dec 25 15:19:22 2014 and was aborted after 89882 seconds
    total bytes scrubbed: 1.87TiB with 4 errors
    error details: csum=4
    corrected errors: 0, uncorrectable errors: 4, unverified errors: 0

К счастью, у меня есть все резервные копии в третичной резервной копии, поэтому я не особенно обеспокоен потерей файлов (я хорошо осведомлен о проблемах, связанных с экспериментальным состоянием BTRFS, у меня есть несколько резервных копий для обеспечения безопасности моих данных, и я решил продолжать использовать его, поэтому, пожалуйста, нет: "Решение; не используйте BTRFS" сообщения).

Я хотел бы знать, однако, как определить, какие файлы связаны с неисправимыми ошибками? Я хочу найти их, удалить их и заменить их резервными копиями.

Если у кого-то есть информация о том, как это сделать, я хотел бы услышать от вас.

Заранее спасибо.

|источник

4 ответа4

8

Я нашел следующий метод полезным ...

btrfs scrub том.

Вы будете представлены с любым количеством ошибок csum, как вы показали выше.
Используя детали вашего примера ошибки: csum = 4 . Используйте это число в директиве tail следующего оператора:

dmesg | grep "checksum error at" | tail -4 | cut -d\  -f24- | sed 's/.$//'

Удобно передать это в файл (например, > csums.txt)

Я попробовал несколько предложенных подходов поиска инода, и все они встретились с ограниченным успехом.

|источник
2

dmesg предоставит вам подробную информацию о файлах, связанных с ошибками контрольной суммы, которые невозможно исправить. Сообщения обычно выглядят так: «BTRFS: ошибка контрольной суммы в логическом [...] в dev [...], секторе [...], root [...], inode [...], смещении [ ...], длина [...], ссылки [...] (путь: [...])"; последняя часть информации - это абсолютный путь к поврежденному файлу.

|источник
2

Да, сопоставление INODE или Block Number с именем файла может быть затруднено. Если вы действительно заинтересованы, вы можете попробовать что-то вроде этого и посмотреть, какие файловые файлы копировать ... в конце концов, если файл плохой, он должен выдать ошибку во время копирования. Я ранее использовал этот тип техники.

 find /mount-point -type f -exec cp {} /dev/null \;

 where mount-point is the ROOT node/mount-point of the affected filesystem
|источник
1

Я пришел сюда в поисках "Неисправимой ошибки" от BTRFS. Вышеупомянутый grep не работал для меня; Я должен был использовать вместо этого:

$ dmesg | sed -n -r 's#.*BTRFS.*i/o error.*path: (.*)\)#\1#p' | sort -u
somepath/somefile.txt

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .