Zdravím,
prosím o záchranu reputace Btrfs a jako vedlejší efekt i 5,28 TiB mých záloh. Volume vykazoval problémy a po spuštění a pádu btrfs check už nejde ani připojit. Popíši to celé chronologicky níže.
Popis
Měl jsem Linux openSUSE Leap 15.3 s jen oficiálními repozitáři. Byl ve VPS na QNAP NAS.
Do něj jsem měl z toho NASu přes ISCSI připojený 5,28 TiB volume obsahující zálohy všech mých serverů na šifrovaném Btrfs. Říkejme mu třeba blokové zařízení /dev/star1/backups:
localhost:~ # blockdev --getsize64 /dev/star1/backups
5798201655296
localhost:~ # blkid /dev/star1/backups
/dev/star1/backups: LABEL="space-backups" UUID="18d0fd43-c0ac-42f6-a480-fb4f02932b00" UUID_SUB="f91d3e0c-46a6-4ab4-b492-1ed211a1d030" BLOCK_SIZE="4096" TYPE="btrfs"
Protože se mi tento Btrfs volume začal přepínat vždy chvíli po bootu do read-only kvůli nějakému problému, spustil jsem na něm btrfs check, ten ale spadl:
krato-nas01-vps-backups:/home/krato # date ; time btrfs check --repair --clear-space-cache v1 --progress --check-data-csum /dev/star1/backups ; date
Mon May 9 17:03:49 CEST 2022
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/star1/backups
UUID: 18d0fd43-c0ac-42f6-a480-fb4f02932b00
Failed to find [6147432235008, 168, 16384]
btrfs unable to find ref byte nr 6147432251392 parent 0 root 2 owner 0 offset 0
transaction.c:195: btrfs_commit_transaction: BUG_ON `ret` triggered, value -5
btrfs(+0x51f99)[0x55a7695aef99]
btrfs(btrfs_commit_transaction+0x1ae)[0x55a7695af58e]
btrfs(btrfs_clear_free_space_cache+0xdc)[0x55a7695a20bc]
btrfs(+0x157fa)[0x55a7695727fa]
btrfs(cmd_check+0x103a)[0x55a7695c4cca]
btrfs(main+0x8e)[0x55a76957c08e]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7febe47e034d]
btrfs(_start+0x2a)[0x55a76957c28a]
Aborted (core dumped)
Po jeho pádu oddíl najednou už ani nešel připojit:
localhost:~ # mount /dev/star1/backups /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/star1-backups, missing codepage or helper program, or other error.
localhost:~ # dmesg -T | tail
[Wed May 11 20:32:53 2022] BTRFS error (device dm-1): open_ctree failed
[Wed May 11 21:25:42 2022] hrtimer: interrupt took 18596350 ns
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): flagging fs with big metadata feature
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): disk space caching is enabled
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): has skinny extents
[Thu May 12 00:17:06 2022] BTRFS info (device dm-1): bdev /dev/mapper/star1-backups errs: wr 1, rd 0, flush 0, corrupt 408, gen 0
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): parent transid verify failed on 6086151716864 wanted 487495 found 487500
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): parent transid verify failed on 6086151716864 wanted 487495 found 487500
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): failed to read block groups: -5
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): open_ctree failed
Protože btrfs check při dalších pokusech opět vždy spadl, nainstaloval jsem novou VPS s openSUSE Tumbleweed, kernel upgradoval na 5.18-rc6 a blokové ISCSI zařízení připojil jen do této VPS:
localhost:~ # head -n 2 /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20220507"
localhost:~ # uname -a
Linux localhost.localdomain 5.18.0-rc6-1.ged50f8f-default #1 SMP PREEMPT_DYNAMIC Sun May 8 21:14:22 UTC 2022 (ed50f8f) x86_64 x86_64 x86_64 GNU/Linux
localhost:~ # btrfs --version
btrfs-progs v5.17
Na něm btrfs check napíše nějaké chyby a pak to vzdá:
localhost:~ # btrfs check /dev/star1/backups
Opening filesystem to check...
parent transid verify failed on 6086151716864 wanted 487495 found 487500
parent transid verify failed on 6086151716864 wanted 487495 found 487500
parent transid verify failed on 6086151716864 wanted 487495 found 487500
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=6086151536640 item=223 parent level=1 child bytenr=6086151716864 child level=1
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system
Zkusil jsem btrfs rescue zero-log a btrfs rescue clear-uuid-tree, ale nepomohlo to.
Zkusil jsem na konec ještě btrfs rescue chunk-recover, ale to se vždy po pár hodiných přeruší s chybovou hláškou:
localhost:~ # date ; time btrfs rescue chunk-recover /dev/star1/backups ; date
Wed May 11 20:35:04 CEST 2022
Scanning: 272670670848 in dev0scan chunk headers error
Chunk tree recovery aborted
real 140m45.289s
user 4m31.873s
sys 25m25.405s
Wed May 11 22:55:49 CEST 2022
Připadá mi, že se to neustále točí dokola jen kolem následující chybové hlášky. Možná je tam jen jeden zádrhel, se kterým si neumí poradit mount a ani check. Tato chyba myslím byla také v dmesg úplně na začátku kdy ještě šel ten oddíl přimountovat a přepnul se po chvíli do read-only:
parent transid verify failed on 6086151716864 wanted 487495 found 487500
Dotaz
Máte někdo prosím nějaký nápad jak to opravit aby to šlo opět přimountovat a číst data?
Jedná se v mém případě "jen" o tisíce záloh různých strojů. Cítím to hlavně jako velkou zkoušku vyspělosti Btrfs. Protože jestli "načatý" Btrfs dokáže "btrfs check" dorozbít, že to už nic neopraví a to na stable Linuxu a kernelu, tak se začnu bát můj velmi oblíbený Btrfs používat kdekoliv.
Mohu vyzkoušet jakoukoliv Vaši radu, ten oddíl jsem právě teď snapshotnul. Bohužel naivně ne už před btrfs check. Teď mi stejně jde hlavně o to, zda se lze na Btrfs spolehnout.