Пошук файлів з BTRFS Uncorrectable помилками


17

У мене виникає питання щодо непоправних помилок у файловій системі BTRFS. Зокрема, я нещодавно запустив скраб BTRFS після того, як зіткнувся з проблемою з однією з моїх паличок оперативної пам’яті, і, здається, виявив 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" публікацій).

Хочеться знати, однак, як визначити, які файли пов’язані з непоправними помилками? Я хочу їх знайти, видалити та замінити їх резервними копіями.

Якщо у когось є інформація, як це зробити, я хотів би почути від вас.

Спасибі заздалегідь.

Відповіді:


8

Я знайшов наступний метод корисним ...

btrfs scrub обсяг.

Вам буде представлено будь-яку кількість помилок csum, як ви показали вище.
Використовуючи детальну інформацію про помилку прикладу : csum = 4 . Використовуйте це число в хвостовій директиві наступного твердження:

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

Це зручно передавати у файл (наприклад > csums.txt)

Я спробував декілька запропонованих підходів до пошуку inode, і всі вони зустрілися з обмеженим успіхом.


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

3

Так, відображення з INODE або номера блоку назад до імені файлу може бути важким. Якщо ви дійсно зацікавлені, ви можете спробувати щось подібне і побачити, які файли файлів скопіювати ... після того, як файл поганий, він повинен видати помилку під час копіювання. Раніше я використовував цей вид техніки.

 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

Ви можете перемістити його в спеціальний каталог, а потім виключити його з подальшого пошуку.
mdpc

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 [...], сектор [...], root [...], inode [...], offset [ ...], довжина [...], посилання [...] (шлях: [...]) "; остання інформація - це абсолютний шлях до пошкодженого файлу.


1

Я прийшов сюди шукати "Нерегульовану помилку" також від BTRFS. Вищеописаний греп не працював для мене; Мені довелося використовувати замість цього:

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

Зверніть увагу на те, наскільки шлях відносно початку пулуміту - не вказуючи, в якому підпульсі він знаходиться. Це, на щастя, для мене не було проблемою.


Що таке somepath/somefile.txt? Схоже, ви вводите це як окрему команду - чи це вихід з команди, яку ви ввели? Якщо все повинно бути одним командним рядком, будь-ласка, не розбивайте командні рядки для відображення - просто введіть його у відповідь як один довгий рядок. Але, що це? Ви надаєте два входи sort(труба та файл)? Або somepath/somefile.txtмається на увазі як вихідний файл? (Не дуже корисно вказувати вихідні файли, якщо вони не є проміжними файлами, які ви знову використовуєте. Люди знають, як обробляти результати; наприклад, трубопроводом.)
Скотт

Чи відповідає це на початкове запитання? Я не можу сказати.
Я кажу, відновіть Моніку

@TwistyImpersonator Ну, це (ІМО) явно мав бути альтернативою відповіді Марка , і це отримало вісім голосів (і це розширення відповіді arrrr ).
Скотт

1
@Scott другий рядок був зразком виводу команди.
хрестоносці
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.