Поиск файлов с неисправимыми ошибками BTRFS

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»).

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

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

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

RedHack
источник

Ответы:

8

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

btrfs scrub громкость.

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

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

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

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

отметка
источник
Насколько я понимаю, вы используете tail для ограничения количества отображаемых строк и игнорирования дубликатов. Я бы порекомендовал использовать, sort | uniqчтобы избавиться от дубликатов, например так:dmesg | grep "checksum error at" | cut -d\ -f24- | sed 's/.$//' | sort | uniq
niklasfi
3

Да, сопоставление 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
Якорь,
источник
Запустив его сейчас, надеюсь, он что-то изменит. Спасибо за ваш совет, я буду информировать вас о результате.
RedHack
1
Извините, но он не работает = / он обнаружил первый файл, вызывающий неисправимую ошибку, но затем отправляет сообщение «устаревший дескриптор файла» на терминал, если я не прерву его. Конечно, он нашел файл, но теперь я не могу понять, как от него избавиться. Должен связаться с списком рассылки BTRFS.
RedHack
Вы можете переместить его в специальный каталог и затем исключить из дальнейшего поиска.
августа
1
Он не будет перемещаться или копироваться, он просто говорит мне, что дескриптор файла устарел. Я даже не могу.
RedHack
Если вы используете cp -v, вы также можете следить за прогрессом: find / -type f -exec cp -v {} /dev/null \; 2> corrupted-files.txt. Однако /proc/kcoreфайл может быть огромным (у меня было 128 ТБ), поэтому операция копирования, скорее всего, зависнет. Поскольку /procкаталог содержит специальные магические файлы, нам не нужно проверять их. Исключить /procкаталог:sudo find / -type f -and -not -path /proc -exec cp -v {} /dev/null \; 2> corrupted-files.txt
ceremcem
2

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

Arrrr
источник
1

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

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

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

crusaderky
источник
Что такое somepath/somefile.txt? Похоже, вы набираете его как отдельную команду - или это результат введенной вами команды? Если все это должна быть одна командная строка, пожалуйста, не разбивайте командные строки на части для отображения - просто поместите это в ответ как одну длинную строку. Но что это? Предоставляете ли вы два входа sort(канал и файл)? Или somepath/somefile.txtэто выходной файл? (Не очень полезно указывать выходные файлы, если только они не являются промежуточными файлами, которые вы используете снова. Люди знают, как обрабатывать результаты; например, по конвейеру.)
Скотт,
Это отвечает на оригинальный вопрос? Я не могу сказать.
Я говорю Восстановить Монику
@TwistyImpersonator Ну, это (IMO) явно предназначено, чтобы быть альтернативой ответу Марка , и это получило восемь голосов (и является расширением ответа arrrr ).
Скотт
1
@ Скотт во второй строке был примером вывода команды.
крестоносцы