Как перевести btrfs в рабочее состояние после сбоя железа?

Question

[bouslayeff]

Есть машина с Linux Mint. Файловая система корневого раздела BTRFS. Обнаружил ее в состоянии read-only. Сразу проверил RAM мемтестом. Память битая. Заменил память, теперь с памятью все в порядке. Но при загрузке BTRFS все равно переходит в режим read-only. В syslog вижу ошибки: "tree first key mismatch detected". Как перевести ее в рабочее состояние?

Answer 1

[Zettabyte]

Но при загрузке BTRFS все равно переходит в режим read-only. В syslog вижу ошибки: "tree first key mismatch detected".

Перед тем, как делать что-либо, скопируйте все важные данные на другой диск и проверьте, что они не битые.
Это особенно важно для БТРФС и вдвойне в вашем случае - неисправная оперативная память.

Если файлы повреждены, то останавливайтесь, дальше не делайте ничего вообще. Нужно заниматься восстановлением информации.

Затем проверьте какая у вас версия btrfs-progs. Нужно, чтобы была больше, чем 5. Если нет, то обновите.

Если вы изучили dmesg и другой полезной информации там нет, а fsck не сообщает ничего интересного, то можно попробовать btrfs check (без --repair! эту команду можно использовать только когда остальные варианты полностью исчерпаны), лучше на несмонтированной файловой системе.
Тут по идее должно появиться больше информации, от которой можно оттолкнуться.

Comments

[bouslayeff]

Запустил btrfs check --force /dev/sda3

Результат:

ERROR: errors found in fs roots
found 13619191808 bytes used, error(s) found
total csum bytes: 12101448
total tree bytes: 600260608
total fs tree bytes: 562675712
total extent tree bytes: 21659648
btree space waste bytes: 106538600
file data blocks allocated: 22918488064
referenced 17799499776

Перед этим энное количество записей типа:

root 349 inode 1346888 errors 2001, no inode item, link count wrong
unresolved ref dir 55472 index 9 namelen 9 name copyright filetype 1 errors 4, no inode ref

В принципе, на этом разделе важных данных нет, только система.

Система грузится, внешне не заметно, что она битая. Но через несколько минут после запуска btrfs переходит в read-only и это видно в dmesg.

Версия btrfs-progs 5.16.2
Дальше repair с флешки или лучше какие-то другие варианты?

У меня еще 2 дополнительных вопроса.

1) Оперативка на всех одна. Означает ли это, что на разделе с данными (ext4) тоже проблемы, просто ext4 менее требовательна и не кричит об этом?

2) Перед заменой RAM я сгоряча удалил все снапшоты btrfs (показалось, что мало места на разделе осталось). Можно было бы откатиться на один из снапшотов в данном случае или даже btrfs сама бы его подцепила?

[Zettabyte]

bouslayeff,

Версия btrfs-progs 5.16.2

Стоит обновить. Они многое добавили в свежих версиях.

В принципе, на этом разделе важных данных нет, только система.

В таком случае, на мой взгляд, однозначно лучшее решение - это переустановка.

Сбойная оперативная память - это известный источник проблем с BTRFS. Известен тем, что в таких случаях очень часто не помогает ничего и восстановить данные не удаётся.
Вы же получается, что "отделались лёгким испугом".

Переустановка будет и проще полноценного разбирательства и надёжнее по полученным результатам.
Кстати, если у вас на этом разделе ничего важного, то не факт, что БТРФС там вам вообще нужна (хотя я не уверен, что эта ФС нужна тем более для важной информации).

Дальше repair с флешки или лучше какие-то другие варианты?

btrfs check --repair обычно считается самым последним вариантом, "пан или пропал", когда всё остальное опробовано и не дало результата.

С ней надо обязательно понимать, что эта команда (как и некоторые другие попытки восстановления btrfs) может сделать хуже и повредить данные необратимо.

Перед заменой RAM я сгоряча удалил все снапшоты btrfs (показалось, что мало места на разделе осталось). Можно было бы откатиться на один из снапшотов в данном случае

С БТРФС сложно гадать, что можно было бы, тем более без диска на руках, но со снэпшотами да, ситуация была бы повеселее (в хорошем смысле). Так что верно, погорячились.

Оперативка на всех одна. Означает ли это, что на разделе с данными (ext4) тоже проблемы, просто ext4 менее требовательна и не кричит об этом?

Тут уж как повезёт.
Может действительно, что-то и повредилось. А может и пронесло. Начните с проверки тех файлов, которые можно удобно проверить на целостность.

[Zettabyte]

bouslayeff,

root 349 inode 1346888 errors 2001, no inode item, link count wrong

Для айнод встречал вот такой скрипт (обратите внимание на комментарии, нужно указать ваши параметры):

#!/bin/bash

inode_list="1346888 322223 31337 100500" # replace with your inode numbers
directory="/home" # replace with your directory

for inode in $inode_list
do
  echo "looking for inode $inode"
  find $directory -inum $inode
done

Вполне вероятно, что файл(-ов) не найдётся. Похожим скриптом можно попробовать их удалить (но это уже лучше делать не бездумно):

inode_list="1346888 322223 31337 100500" # replace with your inode numbers
directory="/home"

for inode in $inode_list
do
  echo "deleting inode $inode"
  find $directory -inum $inode -delete
done

[bouslayeff]

Переустановка будет и проще полноценного разбирательства и надёжнее по полученным результатам.
Кстати, если у вас на этом разделе ничего важного, то не факт, что БТРФС там вам вообще нужна (хотя я не уверен, что эта ФС нужна тем более для важной информации).

Это старенькая машина 15-летней давности, которая была до сих пор задействована только для банковских платежей по 2 часа в месяц. Но недавно я на нее залил торренты и загрузил по полной программе. И сразу read-only в btrfs. Это внушает мне оптимизм, потому что ext4 при этом не отметилась ничем, кроме запуска fsck при загрузке (это я задним числом узнал), а потом работала как ни в чем не бывало. И сколько бы я еще проработал с битой памятью и битыми данными на диске в таком случае? А btrfs сразу вычислила кривое железо!

btrfs check --repair обычно считается самым последним вариантом, "пан или пропал", когда всё остальное опробовано и не дало результата.

Запустил btrfs check --repair с флешки (grml 2024.02, версия btrfs 6+)
Куча ошибок исправлена, судя по выводу. Но ошибки остались, естественно, так как не было избыточности данных. Загружаюсь в Mint, система работает, и btrfs больше не переходит в read-only.

Вот результат (btrfs check --force):

(...) Много записей типа
incorrect local backref count on 318316544 parent 11601936384 owner 0 offset 0 found 0 wanted 1 back 0x5591dbf43cf0
backref disk bytenr does not match extent record, bytenr=318316544, ref bytenr=0
backpointer mismatch on [318316544 8192]

(...) Потом много записей типа
backpointer mismatch on [17160978432 4096]
ref mismatch on [17160982528 4096] extent item 4, found 3
incorrect local backref count on 17160982528 parent 11427397632 owner 0 offset 0 found 0 wanted 1 back 0x5591ddd48880
backref disk bytenr does not match extent record, bytenr=17160982528, ref bytenr=0

(...) Потом много записей типа
unresolved ref dir 409 index 992 namelen 18 name subscriptions.conf filetype 1 errors 2, no dir index

(...) Результат:
ERROR: errors found in fs roots
found 13489639424 bytes used, error(s) found
total csum bytes: 11854028
total tree bytes: 726679552
total fs tree bytes: 687980544
total extent tree bytes: 23232512
btree space waste bytes: 133227555
file data blocks allocated: 35830775808
referenced 27065204736

Как подчистить остатки? Потерянные файлы не проблема. Я просто переустановлю все имеющиеся пакеты. И система как новенькая.

Есть еще команда btrfs rescue. Там интересные опции имеются...

Оперативка на всех одна. Означает ли это, что на разделе с данными (ext4) тоже проблемы, просто ext4 менее требовательна и не кричит об этом?

Тут уж как повезёт.
Может действительно, что-то и повредилось. А может и пронесло. Начните с проверки тех файлов, которые можно удобно проверить на целостность.

Как я понимаю, в etx4 нет способа проверить данные внутри файлов. Явно обнулившиеся, например, видно. А остальные не проверишь средствами ФС, поскольку контрольных сумм нет.