BTRFS replace - zapisuje něco na původní disk?

[stemar]

Dobrý den.

Měl jsem btrfs raid1 na dvou discích, fungoval bez problémů. Teď, zpětně viděno, jen z hloupého rozmaru jsem si usmyslel vyměnit v něm disky za větší. Připojil jsem dva nové větší disky (pro informaci - poněkud pochybného původu) a udělal postupně btrfs replace obou stávajících disků na nové. Proběhlo v pořádku, žádné chyby. Následně jsem tedy ještě udělal už na těch nových discích btrfs filesystem resize abych využil to nové místo.
Celou dobu jsem si (naivně) myslel, že je to celkem bezpečná operace, protože mi pořád zůstávají v záloze ty původní dva disky, v případě problémů se k nim mohu vrátit a ztratím max. ty změny od začátku replace. V zápětí se ukázalo že ty nové disky (SSD) jsou opravdu pochybné, po pár hodinách používání prostě začaly "zapomínat" data na nich mizela a v btrfs device stats začaly přibývat corruption_errs.
Myslel jsem si, že možná bude stačit jen odpojit ty nové disky a restartovat, případně manuálně mountnout ty původní disky. Ale nic z toho se nedaří. Při restartu systém ty původní disky nenajde a pokus o ruční mount hlásí wrong fs type, bad option, bad superblock
On btrfs replace příkaz něco zapisuje na ty původní, zdrojové disky? Nebo je dokonce nějak přepisuje/nuluje? Existuje vůbec nějaká cesta zpět?
Díky

[Reklama]

[Zopper]

Jako úplně první krok teď doporučuji zaběhnout do důvěryhodného obchodu, koupit tam dostatečnou diskovou kapacitu a udělat bitovou kopii původních disků, než si do nich hrábneš ještě víc. A dál se hrabat v té kopii, nezkoušet rozchodit původní fyzické disky.

Z manuálu k btrfs replace:
After completion of the operation, the source device is removed from the filesystem.

Tady to vypadá na trochu víc informací (přepíše se superblok) i s možností obnovy zápisem magických hodnot na konkrétní místo na disku.

[stemar]

dd z původních disků jinam bylo první co jsem udělal. Ten popis obnovy z odkazu vypadá hodně magicky. Zkusím nejdřív nastudovat a pochopit co vlastně dělá a odkud bere ta záhadná čísla.
Ale díky za odkaz, Google jsem samozřejmě zkoušel, asi jsem se ptal špatně.

[Zopper]

Ve zkratce, na tom disku na přesně dané lokaci je informace "tohle je btrfs disk" (to je ta magická hodnota) a v rámci replace příkazu se tahle informace smaže. Pro obnovu je potřeba ji tam zase vrátit (zapsat na konkrétní adresu toho disku). Komplikované je to tím, že superblok, co tu magickou hodnotu obsahuje, se kvůli odolnosti zapisuje duplikovaně na víc záložních pozic v rámci disku, takže to tam dělá 3x.

Ale je to dva roky stará odpověď, nevím, jestli se něco změnilo v superbloku, a nezkoumal jsem, jestli se ty adresy záložních superbloků posunuly.

[stemar]

Jasně, když člověk ví co má hledat (_BHRfS_M) hned se ta informace hledá snadněji:
https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/On-disk_Format.html#Superblock

O něco jsem se pohnul, teď už hlásí
[ 6224.497322] BTRFS: device fsid 2db8f54a-3a36-4e3c-8e1f-6ef781966d66 devid 0 transid 0 /dev/loop30 scanned by mount (7926)
[ 6224.497921] BTRFS info (device loop30): first mount of filesystem 2db8f54a-3a36-4e3c-8e1f-6ef781966d66
[ 6224.497939] BTRFS info (device loop30): using crc32c (crc32c-intel) checksum algorithm
[ 6224.497944] BTRFS error (device loop30): superblock checksum mismatch
[ 6224.497956] BTRFS error (device loop30): open_ctree failed


Nadějí mě naplňuje že to 2db8f54a-3a36-4e3c-8e1f-6ef781966d66 je opravdu UUID toho původního disku/raid1.

[Reklama]

[RDa]

A co jsi to koupil za SSD a kde, ze odchazeji? Minimalne jako varovani pro ostatni, co chteji neco superlevne by to poslouzilo. Neni totiz typicke, ze budou odchazet dva nove disky zaroven. Podle popisu bych tipoval ze jde o fejky

[stemar]

Ano, nejspíš jde o fejky (napsáno je na nich Lenovo). Dostaly se ke mně podivnou cestou, ve které pravděpodobně figuroval nějaký čínský shop (ne že bych je tam kupoval), dostal jsem je jako bonus za nějakou protislužbu. Na nic důležitého bych je nepoužil. I tady jsem si to troufnul jen proto že jsem se (chybně) domníval, že jestli fakt chcípnou, tak se prostě jednoduše a snadno vrátím k původnímu páru.
No - chybama se člověk učí...

[Michal Šmucr]

Teď jsem si to zkoušel v rychlosti nasimulovat. Byť bez RAID1 jen s jedním blok. zařízením (partišnou), co jsem pak vyměnil za jinou pomocí replace.

Podle všeho to opravdu odstraní jen magic (těch 8 bajtů), jakmile jsem v hex editoru zapsal zpátky řetězec "_BHRfS_M", co byl u mě na offsetu 0x10040 od začátku partišny (což odpovídá přesně tomu stack overflow), tak mi btrfs inspect-internal dump-super <device> hlásí i správný checksum superbloku. Připojení s -o ro,degraded pak jde a normálně si přečtu data.

Když jsem pak pustil btrfs inspect-internal dump-super -a <device>, tak mi vypsal i dekadický byte offset na začátek druhé kopie superbloku, v hexeditoru jsem poskočil dopředu o dalších 0x40, a opravil to také tam.

Normálně (bez -o degraded) se mi to připojovat nechtělo, ale v dmesg mi to napovědělo, že:

BTRFS warning (device nbd0p1): cannot mount because device replace operation is ongoing..

Tak jsem po připojení v degraded režimu zrušil replace (btrfs replace cancel <mountpoint>) a už se to připojuje standardně.

Snad se to povede i u vás. Tam mě jen trochu zaráží, že vám to pořád píše checksum failed.

[stemar]

Fakt moc oceňuji tu snahu pomoci. U mě je to nějaké složitější. BTRFS tvrdošíjně hlásí chybu superblock checksum a to na všech kopiích superblocku. Jsem si 100% jistý, že jsem na těch původních discích žádnou operaci nedělal, první operací poté co jsem zjistil že nejdou namountovat bylo dd do souboru na jiném disku a vše ostatní pak probíhalo až tam.
Že ale nějakou záchrannou operaci neudělal proaktivně za mými zády nějaký mountovací démon (Kubuntu), to už si tak úplně jistý nejsem...
Uvidím, celé to vlastně od začátku bylo myšleno jako trénink, rozšíření znalostí o BTRFS, to se tedy naplňuje měrou vrchovatou...