HW disk padající v btrfs RAID 1

17.7.2020 14:58 | Přečteno: 1781× | Linuxové drobty

Nedávno se mi začaly objevovat zprávy v journalu s problémem v mém hlavním btrfs RAID 1 poli. Pole jede nad čtveřicí zašifrovaných LUKS disků. Co mne potěšilo, byl v podstatě velmi brzký záchyt problému. Při pohledu do SMART výsledků byly jen nápadné 4 realokované sektory a jinak nic. Celkový status PASSED. Short SMART test prošel, long SMART test havaroval. Tento poslední výsledek mne přiměl situaci ihned řešit a koupil jsem disk na výměnu. Pole se mezitím při následujícím rebootu nesestavilo, nicméně to mi až tak nevadilo, protože jsem jej již opravoval.

Díky tomu, že btrfs checksum a je schopen zrestaurovat vnitřní bloky, tak jsem zvolil postup.

ddrescue /dev/sdx /dev/sdy disk-log

Kopie zašifrovaných dat. Výsledek ddrescue byl pouhých 16KB nepřečtených dat na 2T disku.

Pak následovala fyzická výměna disku a díky tomu, že disk se skládl na UUID tak se pole automaticky složilo. A následný

btrfs scrub start /mnt/pole

zahlásil asi 17000 opravitelných chyb, žádné neopravitelné chyby a pole bylo v pořádku.

Podle mne včasné varování na problémy s diskem mě zachránilo od větších potíží a btrfs RAID 1 považuji za velmi funkční.        

Komentáře

[Aleš Kapica]

Postrádám zásadní informaci – co to jsou za disky.

[lertimir]

Ten chybující byl WD RED, to kam jsem kopiroval je HGST Ultrastar. Nicméně to není podstatné. To proč jsem blog psal bylo, že z jiných disků stačilo v poslední kroku restaurovat 16kB na to HGST, vše ostatní bylo z padajícho disku. A to druhé ze btrfs RAID problém zahlásil včas, problém měl v checksumech, což mdadm nezjistí. Pro jiný padající disk, který je v mdadm, bude při restauraci nutné přečíst všechno z odpovídajícího disku v RAID10 a je jedno, že je na 3TB pouze asi 200kB porušených.

[Aleš Kapica]

No mě především z toho popisu nebylo jasné jak to vlastně je, protože když napíšeš "Nedávno se mi začaly objevovat zprávy v journalu s problémem v mém hlavním btrfs RAID 1 poli", tak mi automaticky naskočí Btrfs v raid1 multidevice módu, složené z fyzických disků. Ovšem když jsi vzápětí uvedl "Pole jede nad čtveřicí zašifrovaných LUKS disků.", padnul argument, který zcela zásadně mění situaci, protože jde o mezivrstvu a tím pádem Btrfs nemůže mít nejmenší tušení v jakém stavu se nachází fyzické zařízení. Spoléhá tedy na to, že data, co mu vrací ta mezivrstva jsou ok. Pokud nejsou, tak to znamená, že má problém LUKS, nikoliv Btrfs. A tím pádem je titulek, pod kterým jsi ten blogpost uvedl zavádějící. Možná by tomu tak nebylo, kdyby jsi místo "v" uvedl "a".

Jinak ano. Btrfs v raid1 je ideální k tomu, abys mohl včas odhlalit počínající problémy s fyzickým diskem, proto taky žádné mezivrstvy nepoužívám a po pravdě jsme moc divil proč ho používáš nad LUKSem, protože tím (podle mě) zabíjíš veškeré výhody co Btrfs přináší. Osobně bych spíš používal šifrování nad Btrfs, než pod ním.

[lertimir]

složení je

fyzický disk -> LUKS > btrfs Raid

Nicméně tak jsem se s btrfs seznámil, tak btrfs v žádném případě nezjištuje stav fyzického zařízení v jiném smyslu, než že přečte z blokového zařízení data a na příslušném bloku si zkontroluje checksum. V podstatě vždycky

Spoléhá tedy na to, že data, co mu vrací ta mezivrstva jsou ok.

Nižší vrstva LUKS v XTS modu a (stejně si myslím že i v jiných) nemá žádnou kontrolu a vezme blok z disku, prožene ho algoritmem a dodá blok do vyšší vrstvy. A můžeme to chápat jako prosté substituční zobrazení blok na blok, kdy samozřejmě zobrazení závisí na číslu bloku. Pokud btrfs pracuje se stejnými bloky jako LUKS, tak podstavná vrstva nesníží nijak obecnost a spolehlivost btrfs, protože ano při malé chybě v HW dodá LUKS sice zcela jiný blok, ale ten by i při malé chybě btrfs označil jako chybný a řešil chybu na úrovni bloku. Pokud nejsou data z LUKSu ok, není to, že problém má LUKS (pokud by nenastalo nějaké kritické prolomení) ale problém má HW, LUKS ten problém přenese na vyšší úroveň a btrfs ho identifikuje.

A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni. Možná na úrovni souborů, ale tím jsou názvy souborů a struktura adresářů veřejná, veracrypt kontainer a cokoliv, co nevyužije CoW je nesmysl. Jediná nevýhoda, kterou v mém postupu vidím, že stejná data se pro každý disk šifrují jinak, takže zvýšení zátěže u krypto vrstvy. Jinak vše mi připadá OK a tento zvýšený overhead akceptuji.

[Aleš Kapica]

Nicméně tak jsem se s btrfs seznámil, tak btrfs v žádném případě nezjištuje stav fyzického zařízení v jiném smyslu, než že přečte z blokového zařízení data a na příslušném bloku si zkontroluje checksum. V podstatě vždycky

Spoléhá tedy na to, že data, co mu vrací ta mezivrstva jsou ok.

To sice jo, ale z principu, protože jde o COW systém bych řekl že tam dochází k většímu žonglování s daty, protože šifrování produkuje víceméně nedeterministické shluky dat se kterými firmware disku nedokáže efektivně pracovat. Ale nevím. Možná se mýlím.

A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni.

Samozřejmě že v takovém případě se to nedělá na blokové úrovni. Šifrují se data co tečou mezi FS a userspace. Ale nevím. Nepoužívám to, protože mě k tomu nic nenutí a navíc šifrování dat považuji za zbytečnou obstrukci, protože kdo chce data ukrást, tak si najde jiný, mnohem efektivnější způsob, než je louskání čmajznutého zařízení. Ale pokud ti ten zbytečný overhead nevadí, tvoje věc.

[lertimir]

protože šifrování produkuje víceméně nedeterministické shluky dat se kterými firmware disku nedokáže efektivně pracovat.

Myslím, že data firmware disku nezajímají. Kompresované video silnými algoritmy je podobně "nedeterministické" (a myslím tím stream a ne obálku) FW vezme blok a uloží jej na pozici, max si zefektivní mechanické pohyby čtecích hlav. A CoW (ale jakýkoliv FS) ať dělá co chce, tak má elementární operaci s blokem dat a pokud je stejná velikost mezi FS vrstvou a diskem tak je to transparentní. (problém jsou když ty velikosti stejné nejsou a někdy ani nemohou být např standardní RAID 5 nad 4 disky má základní velikost 3 x strip a to není 2^x pro žádné x)

A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni.

Samozřejmě že v takovém případě se to nedělá na blokové úrovni. Šifrují se data co tečou mezi FS a userspace.

Netuším, co tím můžeš myslet. Na úrovni FS potřebuješ zašifrovaná data a v paměti potřebuješ pracovat z rozšifrovanými daty. Pokud na disku nepotřebuješ zašifrovaná data a fyzickou bezpečnost máš zajištěnu jinak, nemusíš šifrovat. Stavět zašifrovaný souborový FS jako ecrypt nad btrfs je také pitomé.

[k3dAR]

[...] šifrování dat považuji za zbytečnou obstrukci, protože kdo chce data ukrást, tak si najde jiný, mnohem efektivnější způsob, než je louskání čmajznutého zařízení [...]

pokud nesifrujes tak nemusi nic louskat ani hledat jinej zpusob jak zistat data, kdyz mu je rovnou "das" nesifrovana

[alkoholik]

RAID1, jeden vadny disk a "Pole se mezitím při následujícím rebootu nesestavilo" zni spis jako nocni mura nez pouzitelny nastroj.

[Cabrón]

On to totiž není RAID1. Je to jen alias pro "dup", tj. existují dvě kopie objektu (blok nebo metadata) a každá je na jiném fyzickém disku. Když máte disky 4, pořád jsou jen dvě kopie objektu a tolerance selhání právě jednoho disku.

Že se to nesestavilo je správně, btrfs to imlicitně odmítne a musíte mu to odkejvat s mount -o degraded ... (nebo si ten "souhlas" dát do fstabu či linux cmdline).

[alkoholik]

No doufal jsem, ze cele to saskovani s ddrescue byla v zasade chyba, ktera mu mohla leda tak roz***t data.

[lertimir]

Naopak. To je zpráva ztrácíš redundanci, vyřeš to. Pokud někoho ztráta redundance nebolí a vyhovuje mu, že pole "nějak běží" tak je je to jiný přístup.

[k3dAR]

pokud by systemd emergency nahazovalo sit+ssh tak by to bylo ok, ale protoze ne, tak mi prijde lepsi pri restartu vzdaleneho stroje (bez ipmi ci kvm-over-ip) ze mi prijde mail "pole je degradovane" a ja to muzu resit, nez ze je potreba fyzicky ke stroji dorazit

[alkoholik]

Mail "pole je degradovane" ma prijit ve chvili, kdy degraduje. To neni vazane na boot.

[alkoholik]

Na degradovanem poli to pobezi vsem az do pristiho rebootu nebo vymeny. Zadny "jiny pristup" nikde nevidim.
Rozbity disk ma znamenat jenom hotswap za novy. Nevidim absolutne zadny duvod, proc by mi mel rozbit bootovani, kdybych ho nahodou nestihnul nahradit.

[Andrej]

Nikoliv. Tohle je naprosto správná reakce na ztrátu redundance. Je dobře, že se konečně opravdový RAID takhle chová. Názory, že pole, které má garantovat redundanci, by se mělo bez redundance jen tak sestavit a fungovat, jsou hluboce zakořeněná pověra, která ne a ne chcípnout.

Situace s jedním poškozeným diskem v RAID1 se (zcela správně) považuje za kritickou. Data v takové situaci "bojují o holý život", řečeno patosem. Jediným a prvořadým cílem musí být obnovení redundance, nikoliv "obvyklý" provoz systému.

Kdyby se filesystém namountoval, jako by nic, dovedu si živě představit davy takyadministrátorů bez řádného monitoringu, jak by to napřed pár měsíců nepostřehli, pak by to dalších pár měsíců nechali dál "fungovat", když to do té doby "fungovalo", a nakonec by selhal i druhý / další disk.

Řekl bych, že Facebook i řada dalších uživatelů Btrfs v business-critical nasazení ví velmi dobře, proč jim zrovna tohle chování vyhovuje.

[k3dAR]

pokud by pri 4x Disk v RAID1 delalo opravdovej RAID1, tedy mirror pres vsechny disky, nikoliv pouze block vzdy jen na dva, tak by toto degradovani kriticke nebylo... i kdyz BTRFS dedela opravdovej RAID1, a kvuli obavam o data pri rebootu nesestavi pole, melo by alespon pripravit emergency consoly s dostupnym SSH, aby kompetentni admin usoudil zda nez se fyzicky dostavi na misto muze server nastartovat, nebo zda ma cekat nenastartovanej...

[Andrej]

pokud by pri 4x Disk v RAID1 delalo opravdovej RAID1, tedy mirror pres vsechny disky, nikoliv pouze block vzdy jen na dva, tak by toto degradovani kriticke nebylo...

Aha — takže 4 disky by měly mít v raid1 profilu kapacitu jednoho disku, podle tvého světonázoru?

Mimochodem, ráčil ses obtěžovat přečíst si dokumentaci? Tipuju, že (jako obvykle) ne. Proč číst dokumentaci, když se dá střílet od boku, že jo… Inu, je to takhle:

• raid1 — 2 kopie, 1/2 kapacity
• raid1c3 — 3 kopie, 1/3 kapacity
• raid1c4 — 4 kopie, 1/4 kapacity

Takže, kdyby tazatel opravdu (ale opravdu) chtěl 4 kopie — výměnou za polovinu kapacity ve srovnání s raid1 —, asi by zvolil raid1c4, ne?

Pojďme se ještě bavit o tom, jestli by se degraded pole s jedním chybějícím diskem mělo automaticky namountovat v raid1c4, dejme tomu.

Ne, nemělo.

Proč? Inu, ze stejného důvodu, ze stejného principu: Souborový systém má garantovat odolnost proti selhání kterýchkoliv 3 disků. Je v situaci, kdy tuhle odolnost garantovat nedokáže. Tedy situace je kritická a je na uživateli, aby rozhodl, jak ji řešit. To je stejná situace jako u raid1, jenom jiné N.

Pokud někdo s touto^^^ zásadou nesouhlasí, řešení je jednoduché: přidat do příkazové řádky kernelu rootflags=degraded (a někdy taky přidat degraded do /etc/fstab). Hotovo. Pak se to namountuje stůj co stůj, žádný problém, a řádný monitoring si musí uživatel zajistit po svém. Nebo taky ne; to už je jeho problém.

…i kdyz BTRFS dedela opravdovej RAID1, a kvuli obavam o data pri rebootu nesestavi pole, melo by alespon pripravit emergency consoly s dostupnym SSH, aby kompetentni admin usoudil zda nez se fyzicky dostavi na misto muze server nastartovat, nebo zda ma cekat nenastartovanej...

Huh? Cože? Že by jako Btrfs měl znova vynalézt kolo a vymyslet to, co normálně dělá + má dělat userspace v initramdisku? Jako vtip dobré.

Emergency shell je už asi tak 10+ let normální věc, ve které skončí každé distro, když se nepodaří otevřít a namountovat kořenový souborový systém. Nic nového pod sluncem. Tam se dají taky upravit parametry Btrfs.

Jestli má initramdisk SSH přístup, to už je věcí nastavení — nikoliv úkolem pro Btrfs. Serverový hardware má sériovou konzoli na odděleném ethernetu, takže mít SSH přístup do initramdisku by byl těžký overkill; stačí vzdálený přístup na sériovou konzoli. Hardware jiný než serverový je většinou vedle na stole, takže se bez SSH přístupu do initramdisku obejde.

Proč nemá initramdisk (většinou) lepší podporu pro Btrfs než obecnou konzoli, na to se ptej všech těch distribucí, které mají přes deset let zpoždění v zavádění Btrfs jako implicitního souborového systému. Dokud nebude Btrfs implicitní souborový systém, těžko se dá čekat 100% podpora pro jeho pokročilé funkce v initramdisku. Naštěstí se doba konečně mění a Fedora bude mít konečně (proč to 10 let trvalo???) Btrfs jako implicitní souborový systém. Snad se pak i podpora v initramdisku + dracutu výrazně zlepší.

[k3dAR]

1. raid1cX je vlastnost uvedene kdy, pred par mesici?
2. nemusi jit (a v praxi nejde) o 1/4 disku disku, ale oddilu, kdy se 1 malej (jednotky az desitky GB) udela raid1, druhej pak raid5/6/10/atd...
3. o rootflags=degraded sem nevedel
4. kdyz budem uvazovat ze "bod 3" by nebyl, tak btrfs pokud by znemoznilo boot v degradovanem rezimu, tak by samozrejme nemuselo zarizovat userspace, ale pouze "donutit" stavajici (systemd) emergency rezim aby umoznil vzdaleny pristup, jen SSH do initramdisku nestaci, protoze systemd ho nespusti pred emergency, myslim ze ani nenahodi sit, kdyz sem to pred casem zkousel "donutit" upravama poradi/priorit atd, stejne se mi nepodarilo, coz samozrejme neznamena ze kdo systemd zna to udela hned...

[alkoholik]

Ne podle svetonazoru, ale podle definice RAID1: RAID 1 consists of an exact copy (or mirror) of a set of data on two or more disks; a classic RAID 1 mirrored pair contains two disks. This configuration offers no parity, striping, or spanning of disk space across multiple disks, since the data is mirrored on all disks belonging to the array, and the array can only be as big as the smallest member disk.
Ze btrfs vynaleza hranate kolo, neni muj problem.

[Andrej]

Btrfs vynalézá jako první kolo, protože předchozí AIDy bez R ho nevynalezly. Nějaké další dotazy k tomu?

[alkoholik]

Doprdele uz.
RAID1-6 jsou naprosto jasne definovane. Btrfs v tom dela akorat bordel, protoze rika RAID1 necemu, co RAID1 proste neni.
Howg.

[Andrej]

Netušíš, která bije. Howgh. A ještě se tím chlubíš. Doprdele šulin čurák piča už.

RAID 1-6 jsou naprosto jasně definované — bezva —, jenže žádná údajná implementace takové definice nesplňovala, dokud nepřišel ZFS a poté Btrfs.

ZFS a Btrfs poprvé implementují skutečnou redundanci. Bez planých slibů, s rozumně definovanými garancemi, atomicitou atd.

Na ZFS nebo Btrfs selhání jednoho disku nikdy neposere všechna data na RAID1, RAID 5 nebo RAID 6. Na nějakém fosilním nesmyslu, který je údajně jasně definovaný, přesně totéž selhání jednoho disku pošle do kytek všechna data. Už se to tady řešilo asi tak stokrát. Už je ten anti-Btrfs FUD fakt únavný.

Nechceš používat rozumný filesystém? Nemáš rád svá data? Dobře! Ale proč si to nenecháš pro sebe? Proč se tím chceš chlubit?

Zatímco Btrfs a ZFS opravdu garantují redundanci, AID bez R (tedy jakýkoliv údajný RAID před ZFS a Btrfs) nikdy nic negarantoval a naivně spoléhal na funkce (modelově dokonalých) disků, které zmizely v době, kdy se kapacita přehoupla přes 100 GB nebo tak. Jinými slovy, de facto negarantoval nic, zatímco de reklamí žvásty garantoval modré z nebe.

[alkoholik]

Ty jsi vazne pomalejsi. Takze jak u blbecku na dvorecku jeste jednou. RAID1 jasne rika, ze na vsech discich jsou stejna data.
Btrfs vymyslelo neco jineho, tak at tomu kurva drat nerika RAID1!

[Andrej]

Ty jsi ale trouba k pohledání!

Kde přesně RAID1 něco říká?

Kde přesně RAID1 říká, že na všech discích jsou stejná data?

Ale hovno. Nikdy na všech discích nejsou stejná data. Už proto, že tam vždy musí být metadata, ať už jde o AID bez R nebo skutečný RAID, a ta metadata musí obsahovat nějakou unikátní (unikátní — chápeš, co to znamená, jo?) identifikaci každého disku.

Ach jo. Anti-Btrfs FUDisté a jiní mamlasové jsou únavní a otravní. Už to fakt stačí. Nemáme rok 2010.