LINUX.ORG.RU
ФорумAdmin

Восстановление файловой системы с BTRFS после аппаратного сбоя хоста

 , , ,


0

3

Такая проблема:

Имеется виртуальная машина на которой запущенны контейнеры. Один раз отволился на хостовой машине коннектор питания от жёсткого диска. После этого теперь файловая система с этим контейнером уходит в read only. При попытке исправить файловую систему возникает:

root@lxd-two:/var/snap/lxd/common/lxd/disks# btrfs check --repair ./default.img 
enabling repair mode
Opening filesystem to check...
warning, bad space info total_bytes 2147483648 used 2147725312
Checking filesystem on ./default.img
UUID: 5b91b327-bce3-4e45-a7ee-86fa0a774573
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
ref mismatch on [3582070784 94208] extent item 0, found 1
data backref 3582070784 root 438 owner 559207 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582070784 root 438 owner 559207 offset 0 found 1 wanted 0 back 0x55b659277050
backpointer mismatch on [3582070784 94208]
repair deleting extent record: key [3582070784,168,241664]
adding new data backref on 3582070784 root 438 owner 559207 offset 0 found 1
Repaired extent references for 3582070784
ref mismatch on [3582164992 114688] extent item 0, found 1
data backref 3582164992 root 516 owner 18532 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582164992 root 516 owner 18532 offset 0 found 1 wanted 0 back 0x55b6790b4a20
backpointer mismatch on [3582164992 114688]
adding new data backref on 3582164992 root 516 owner 18532 offset 0 found 1
Repaired extent references for 3582164992
ref mismatch on [3582279680 12288] extent item 0, found 1
data backref 3582279680 root 516 owner 18591 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582279680 root 516 owner 18591 offset 0 found 1 wanted 0 back 0x55b67ac215c0
backpointer mismatch on [3582279680 12288]
adding new data backref on 3582279680 root 516 owner 18591 offset 0 found 1
Repaired extent references for 3582279680
ref mismatch on [3582291968 12288] extent item 0, found 1
data backref 3582291968 root 542 owner 61178 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582291968 root 542 owner 61178 offset 0 found 1 wanted 0 back 0x55b67b4e5b90
backpointer mismatch on [3582291968 12288]
adding new data backref on 3582291968 root 542 owner 61178 offset 0 found 1
Repaired extent references for 3582291968
ref mismatch on [3582304256 8192] extent item 0, found 1
data backref 3582304256 root 542 owner 61287 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 3582304256 root 542 owner 61287 offset 0 found 1 wanted 0 back 0x55b67ad842d0
backpointer mismatch on [3582304256 8192]
adding new data backref on 3582304256 root 542 owner 61287 offset 0 found 1
Repaired extent references for 3582304256
Failed to find [29638656, 168, 16384]
btrfs unable to find ref byte nr 29720576 parent 0 root 2  owner 0 offset 0
transaction.c:195: btrfs_commit_transaction: BUG_ON `ret` triggered, value -5
btrfs(+0x3b748)[0x55b6539de748]
btrfs(btrfs_commit_transaction+0x12a)[0x55b6539debcc]
btrfs(+0x55861)[0x55b6539f8861]
btrfs(cmd_check+0x1288)[0x55b6539f9e75]
btrfs(main+0x1f3)[0x55b6539b6e63]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f08f464409b]
btrfs(_start+0x2a)[0x55b6539b6eaa]
Aborted

Как теперь исправить файловую систему?

★★★★★

Ты образ хотя бы сделал перед тем, как btrfs check --repair пускать?

TL;DR — монтируй в ro, вытаскивай файлы, пересоздавай. Если не монтируется вообще никак, то btrfs restore.

При внезапной потере питания я бы ожидал transid verify mismatch, но это не оно, значит, скорее всего баг в btrfs. Версия ядра какая?

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от X512

В BtrFS журнал так и не осилили? С журналом повреждения внутренних структур ФС невозможны если диск исправен

Btrfs использует CoW вместо журналирования записей. При исправном железе эти два подхода имеют эквивалентную крахоустойчивость. Но см. выше, здесь скорее всего баг в коде btrfs.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

здесь скорее всего баг в коде btrfs

В этом вся проблема. BtrFS часто глючит, причём разные независимые реализации как под Линуксом, так под Windows/ReactOS. И это я ещё серьёзно не нагружал. В Haiku у меня часто бывают kernel panic и принудительные выключения, но с данными всё в порядке. Может быть журнал проще сделать чем CoW и в нём сложнее допустить баги?

X512 ★★★ ()
Ответ на: комментарий от X512

В этом вся проблема

Это, безусловно, проблема, но не та, о которой ты заявил вначале.

Плюс, мы не знаем, насколько новое у топикстартера ядро.

причём разные независимые реализации

На то они и независимые реализации, чтобы быть менее стабильными, чем основная (на которой сосредоточено наибольшее количество усилий). И да, мне известно ровно две реализации Btrfs, включая ту, что в ядре Linux.

В Haiku у меня часто бывают kernel panic и принудительные выключения, но с данными всё в порядке.

Тут тоже с данными всё наверняка в порядке (или по крайней мере было до запуска btrfs check --repair).

Может быть журнал проще сделать чем CoW и в нём сложнее допустить баги?

Совершенно точно. Традиционные файловые системы вида «таблица+журнал» устроены значительно проще.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от X512

Может быть журнал проще сделать чем CoW и в нём сложнее допустить баги?

Проще, но зачем оно такое убогое? Сейчас актуальны ZFS, APFS, Btrfs. ReFS рипнулась, к сожалению, так что на Windows у нас нормальной ФС пока нет.

anonymous ()
Ответ на: комментарий от intelfx

Btrfs использует CoW вместо журналирования записей. При исправном железе эти два подхода имеют эквивалентную крахоустойчивость.

если для cow делать транзакции то по логике получится тот-же журнал, а без них не очень очевидна крахоустойчивость в целом

rukez ★★★ ()