Unmountable btrfs: bad tree block start

[Petr Kratochvíl]

Zdravím,

nenapadne prosím někoho nějaká rada jak zkusit zachránit data?

Mám 40 TB Btrfs (obsazeno 32 TB) šifrované přes dm-crypt/LUKS ležící na diskovém poli mdadm RAID 6. Používám kompresi zstd, zapnuté datacow a checksum a mám tyto verze software (měly by být aktuální): OS Xubuntu 18.04.1 LTS, kernel 4.18.14-041814-generic, btrfs-progs 4.17

Prováděl jsem několik btrfs receive a mazal pár desítek subvolumes (je jich tam cca 800), když v tom jsem si všiml, že jeden subvolume nejde otevřít (chyba stejná jako dole v citaci z dmesg). Pole nešlo odpojit, že prý je používané, tak jsem restartoval.

Po restartu na mě bafá error:

Kód: [Vybrat]

root@krato-space:~# mount /dev/mapper/space /space
mount: /space: chybný typ souborového systému, chybný přepínač, chybný superblok na /dev/mapper/space, chybí kódová stránka nebo pomocný program nebo jiná chyba.


Kód: [Vybrat]

root@krato-space:~# mount /dev/mapper/space /space -o ro,nodatacow,nodatasum,rescan_uuid_tree,usebackuproot,nologreplay
mount: /space: chybný typ souborového systému, chybný přepínač, chybný superblok na /dev/mapper/space, chybí kódová stránka nebo pomocný program nebo jiná chyba.

V dmesg:

Kód: [Vybrat]

[ 1417.319669] BTRFS info (device dm-5): force zstd compression, level 0
[ 1417.319672] BTRFS info (device dm-5): setting nodatacow
[ 1417.319682] BTRFS info (device dm-5): disk space caching is enabled
[ 1417.319683] BTRFS info (device dm-5): has skinny extents
[ 1526.548506] BTRFS error (device dm-5): bad tree block start 10958796935674774848 24225444036608
[ 1526.559154] BTRFS error (device dm-5): bad tree block start 5626120839175671030 24225443971072
[ 1526.559180] BTRFS error (device dm-5): failed to read block groups: -5
[ 1526.638363] BTRFS error (device dm-5): open_ctree failed

Zoufalý pokus o záchranu dat jejich vydolováním nevyšel:

Kód: [Vybrat]

root@krato-space:~# btrfs restore -smvio /dev/mapper/space /star1/restore/
Restoring /star1/restore/smartphones
Restoring /star1/restore/smartphones/App_Backup_Restore
Restoring /star1/restore/smartphones/App_Backup_Restore/personal
Restoring /star1/restore/smartphones/App_Backup_Restore/personal/Archive_2_20170802_014258.txt
ERROR: btrfs not compiled with zstd support
Error copying data for /star1/restore/smartphones/App_Backup_Restore/personal/Archive_2_20170802_014258.txt
Restoring /star1/restore/smartphones/App_Backup_Restore/personal/Archive_3_20180503_044336.txt
ERROR: btrfs not compiled with zstd support
Error copying data for /star1/restore/smartphones/App_Backup_Restore/personal/Archive_3_20180503_044336.txt
Restoring /star1/restore/smartphones/App_Backup_Restore/personal/Archive_2_20180503_044336.txt
ERROR: btrfs not compiled with zstd support
...

A oprava také ne:

Kód: [Vybrat]

root@krato-space:~# btrfs check --repair -p /dev/mapper/space
enabling repair mode
checksum verify failed on 24225443971072 found CE56CADF wanted 623CE031
checksum verify failed on 24225443971072 found CE56CADF wanted 623CE031
bytenr mismatch, want=24225443971072, have=5626120839175671030
ERROR: cannot open file system

Nemluvě o tom, že běh btrfs check se mi ani dříve nikdy nezdařil, protože vždy po pár hodinách došla fyzická RAM 8 GB a nevyšel ani jeden pokus na PC s RAM 48 GB. Swap mám také a velký, ale btrfs check ho nerad používá, ale to je teď jedno.

Nelze nějak příkazu mount vnutit aby ignoroval (přeskakoval) problém "bad tree block start"? Existuje jakékoliv řešení jak se dostat alespoň k většině těch 32 TB dat?

[Reklama]

[Lol Phirae]

Existuje jakékoliv řešení jak se dostat alespoň k většině těch 32 TB dat?

Samozřejmě - normálně to obnovíš ze zálohy. 

[ET]

Vystrel naslepo (BTRFS ani *buntu nepouzivam), pouzivaji i ostatni volumes kompresi? Nemohl to rozbit update?

ERROR: btrfs not compiled with zstd support

[Petr Kratochvíl]

Vystrel naslepo (BTRFS ani *buntu nepouzivam), pouzivaji i ostatni volumes kompresi? Nemohl to rozbit update?

ERROR: btrfs not compiled with zstd support

Díky i za výstřel. Btrfs umí už dlouho komprese zlib a zlo, ale zstd se naučilo teprve v listopadu 2017. Zkompiloval jsem si vlastní btrfs-progs s kouzelným argumentem "--enable-zstd" u configure. Nyní již btrfs-restore něco obnovuje. Mám podezření, že jen něco, ale lepší než nic. Tiše doufám, že neobnoví data, u kterých mu nebude sedět checksum (neví někdo?).

Zálohy mám, ale stručně řečeno roztroušené na 5 až 10 různých místech a nějaká nejnovější data v nich ještě chybí.

[kkt1]

Njn, pro priste si se poucil ze je dobre mit aktualni zalohy. 

[Reklama]

[Lol Phirae]

Njn, pro priste si se poucil ze je dobre mit aktualni zalohy. 

No, zejména když si narvu desítky TB dat na filesystém, kde si zapnu experimentální featuru zjevně nepodporovanou v distribuci. Uffffffff. 

[Kamui]

Na vydolování dat by měl pomoct "btrfs restore" (https://btrfs.wiki.kernel.org/index.php/Restore). V podstatě to udělá to, že projde všechna data na disku a co jde vykopíruje ven. Už jsem takhle z jednoho rozbitého FS soubory tahal, povedlo se bez problémů.

[kkt1]

Na vydolování dat by měl pomoct "btrfs restore" (https://btrfs.wiki.kernel.org/index.php/Restore). V podstatě to udělá to, že projde všechna data na disku a co jde vykopíruje ven. Už jsem takhle z jednoho rozbitého FS soubory tahal, povedlo se bez problémů.

nad 30TB dat? 

[Petr Kratochvíl]

Na vydolování dat by měl pomoct "btrfs restore" (https://btrfs.wiki.kernel.org/index.php/Restore). V podstatě to udělá to, že projde všechna data na disku a co jde vykopíruje ven. Už jsem takhle z jednoho rozbitého FS soubory tahal, povedlo se bez problémů.

Díky. To je přesně to, co zkouším. Bohužel mi to obnovuje často jen části souborů, takže nevím, zda se na to spoléhat. Např. obnoví adresář s 20 soubory *.tgz, každý má podle ls -l velikost 50 GB. Celkem mají podle du -h velikost 15 GB a opravdu ani u jednoho kontrola tar ztf <filename.tgz> neprojde. Takto jsem obnovil cca polovinu adresářů, měly by zabírat min. 16 TB, zabírají ale necelé 3 TB. Možná to souvisí s tímto dotazem, který se při obnově často objevil (přesměroval jsem příkaz yes na stdin, ať nemusím zadávat 'y' ručně):

Kód: [Vybrat]

We seem to be looping a lot on /nas-real/restore-space/video/LinuxDays-roomdays/LinuxDays 2018 - neděle - Místnost 105.mp4, do you want to keep going on ? (y/N/a):

Znamená tento dotaz, zda má obnovit soubor s tím, že v něm nechá "díry" (sekvence nenaalokovaných NULLů) a nebo jinak že ten soubor usekne na místě první chyby dat (místo aby ho smazal, což bych uvítal víc)?

Jinak jedna záloha celého pole se zrovna vytvářela a soukala ven přes internet, ale stihl se zazálohovat cca 1 TB. Dalších 13 TB vyštrachám z disků po šuplíkách a zbytek? Snad jen osobní data, většina z toho zálohy. Beru to tak, že alespoň už ta data nebudu muset třídit a také toho volného místa najednou...

Až si budu příště hrát s Btrfs, rád bych celý Btrfs oddíl (resp. blokové zařízení) snapshotoval, ale jak na to? Když kernel vidí dvě Btrfs blokové zařízení se stejným UUID, tak je automaticky považuje za jeden celek (jako je RAID 0). Proto sami autoři vytváření bitových kopií nedoporučují, tj. vytvářet LVM snapshoty není dobrý nápad, viz https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices . Někdo nějaký nápad jak snapshotovat Btrfs oddíl jako takový (tj. ne subvolume)? Díval jsem se, zda umí LVM vytvořit skrytý snapshot, ale vypadá to, že neumí, viz z man lvcreate: "But for example, snapshots can only be created in the active state so -an cannot be used with --snapshot."