Dotaz: Ext4, 16TB HDD a 11 dnů běžící fsck

[Dramon]

Chtěl bych se zeptat, co si do budoucna počít s situací, kdy mi fsck nad ext4 LVM diskem běží již 11 dnů a nachází se ve fázi "1D", kdy to kontroluje překřížení souborů nebo tak něco a já jsem z toho celej nepříčetnej.
Už jen kvůli tomu, že když by to člověk zastavil a spustil znovu, tak to začíná od začátku.

Mám zahodit ext4 a přejít na XFS, které je pro RHEL 7 výchozí a tento problém se mi již nikdy nestane, protože například

• XFS má rychlejší/chytřejší/více jader podporující fsck, resp.xfs_repair
• XFS je na velká data prostě lepší

Nebo to dopadne tak, že až mi párkrát upadne server, tak se mi XFS rozbije tak, že z něho už nic nevytáhnu a bude pokoj :( ?

Díky předem všem, kteří mají dlouhodobou zkušenost s provozováním takto velkých (a větších ) dat, za pomoc.

Odpovědi

[dustin]

ext4 na datových discích nepoužíváme, ale máme 11TB pole nad XFS. Obsahuje deduplikovaný strom backuppc s cca půl miliardou souborů, SW RAID10 s 8 SATA disky. xfs_repair na tom trvá několik hodin, ale sežere přes 30GB RAM. Server má RAM dostatek (128GB), na starším s 8GB RAM jsme to řešili dočasným přidáním swapu na SSD. Při pomalém swapu na HDD by to bývalo trvalo dny.

Není problém zrovna v tom, že ta kontrola vyžrala paměť a jede do pomalého swapu? Nevím, jen se ptám, tohle byl konkrétně problém u nás.

[Dramon]

RAM mám zabráno 500MB z 5 GB, vytížené je jedno jádro ze 4.
Když si zobrazím IO, tak to vlastně s HDD nic nedělá, jen si to šmrdolí s tím jedním jádrem a jednou za čas to vyhodí hlášku "Clone multiply-claimed blocks".
Stroj je jen odkladiště na druhý level záloh, takže kromě disků to je taková plečička. Ale můžu upgradovat
Umí ten xfs_repair aspoň používat více jader?

[dustin]

Nemyslím si. Ale jak píšu, veliký strom to dává za několik hodin.

[j]

To ze to trva 11 dnu spis ukazuje na to, ze ten disk(y) neni uplne zdravej a snazi se dopocitavat data (mineno to LVMko). Tyhle chyby se objevujou trebas v situaci, kdy to natvrdo vytahnes z elektriky (na EXT).

Vic jader ti moc nepomuze, vzdycky ses omezenej IOps disku. Pricemz pri hromade pidisouboru se klidanko muzes dostat i pod 1MB/s per disk.

[Dramon]

Disky si myslím, že jsou fajn, minimálně SMART nic nehlásí a jsou relativně nové.

Když si pustím iostat, tak je vidět, že na disky to v podstatě vůbec nešahá.

[tomo_tn]

Zdravim,

ku tomu XFS - som za, pouzivam ho uz roky bez vacsich problemov, kedysi ked sa XFS s linuxom este len zacinalo kamaratit bolo mazanie malych suborov fakt bolestive, myslim ze sa mi ich podarilo skor nakopirovat ako zmazat :) To sa ale bavime o dobe kernelu 2.4. + externe patche pre XFS. Od tej doby sa vsetko velmi zmenilo, XFS sice stale nemaze tak ako ine FS ale zapis/ prechadzanie/ vyhladavanie su mnohokrat rychlejsie (poznamka nikdy nemazte vela suborov cez mc - to sa neda dockat). Na 2 stranu nieje problem mazat a zapisovat na disky naraz. Dalej XFS naozaj cachuje o106 takze pamat v pocitaci je aspon k niecomu -- mam 8GB a zriedkakedy sa dostanem nad 2GB vytazene aplikaciami. Na desktope sa po chvili prestane z HDD citat takmer uplne - vsetko uz je v RAM, obcasne bliknutie pola nieje ani pocut :)

Presiel som si z XFS tieto konfiguracie:

linux + sw raid cca 6 SCSI diskov, kernel 2.4.xx irix - desktop 6.5.2x linux + rw raid battery backed up chache 4 disky pouzivane ako desktop 4.12+

jedinky krat co sa mi nepodarilo cez xfs_repair FS znova rozchodit bol ten linux + sw raid v davnoveku. Ano XFS ked si nieje 100% isty konzistenciou suboru radcsej vyhodi 0 subor ako nieco potichu pokazene. Vtedy treba pouzit samozrejme zalohu. Inak je to FS co nahodis (pre polia je dobre si pozret vhodne mkfs.xfs prepinace a upravit si hodnoty podla seba)a neriesis, mal som 1-2 nahle vypadky napajania a system nabehol v pohode i data tam boli vsetky, ale ako hovorim mam desktop takze vecsinu casu je vsetko zapisane na platniach a nie niekde na pol ceste.

[Kandidat vied]

odporucam JFS.

[Dramon]

Můžu poprosit o nějaké detaily, co se nevyčtou v manuálu, ale je nutné je získat praxí?
Třeba jak to zvládá velikosti v řádek desítek TB, jak rychlá je oprava, jak náchylné to je na rozsypání po tvrdém resetu, jak rychlé je fsck a jak bývají opravy úspěšné?

[multi]

Taktez doporucuji JFS. Prave z duvodu pomaleho FSCK u ext3 jsem presel na JFS.

[Heron]

Máte s tím někdo nějaké větší zkušenosti? Kdysi (to už bude víc jak 10 let), jsem to na doporučení kohosi vyzkoušel, (paralelně, to je asi podstatné), nakopíroval desítky GB dat a potom se to četlo asi tak 3MB/s a bylo slyšet, jak disky neustále seekují. Podotýkám, že to byly velké soubory (řádově GB) a na jiném FS se to četlo sekvenční rychlostí disku. Pro sebe jsem si z toho udělal ten závěr, že to má špatný alokátor a že to nedokáže správně rozmístit data na disku, pokud se jich tam kopíruje víc naráz.

Podotýkám, že z jednoho "testu" nedělám žádné závěry, dneska už JFS stejně používat nebudu (máme BTRFS a ZFS), ale jen mě to zajímá. (Už jen proto, že o tomto FS prakticky vůbec není slyšet.)

[lertimir]

XFS na velká data je lepší, horší je při práci s velkým množstvím malých souborů, obzvlášt mazání velkého množství malých souborů je výrazně pomalejší než u ext4. ALE. XFS má na druhou stranu hodně dat i metadat v RAM a naprosto nedoporučuji jej do situace bez UPS. Za posledních 10 let mě snad potkala jedna sitace s výpadkem a několik situací kdy se desktop "pověsil" a šel jen natvrdo vypnout Ext4 i v poslední době btrfs byly bez problémů, ale tohle je přesně situace, která může narušit XFS natolik, že nejenže oprava trvá dny ale nejde opravit vůbec, moje zkušenost. (nicméně to se mi s XFS stalo kolem roku 09 a dočetl jsem se, že ve FS byly v posledníczh letech velmi významné změny a proto tohle nemusi být relevantní informace)

[alkoholik]

Neni to tak davno, kdy se XFS po fschecku po vypadku napajeni tvarilo OK, ale nektere soubory mely nulovou velikost.

[Dramon]

Tak tohle jsou přesně ty případy kterých se bojím, že nastanou
S Ext mám zatím (uvidíme co bude, až mi fsck doběhne ) dobré zkušenosti. Sice vypisuje romány, ale data jsou pak OK.

Stejně zvažuju nějaké automatické md5 buď do EA nebo do .MD5 souborů v adresáři. Že se něco poškodí mi ani tak nevadí, ale že nepoznám, že se to poškodilo, tak to vadí víc.

[Aleš Kapica]

Sice vypisuje romány, ale data jsou pak OK.

Tak ti přeju pěkné počtení. Já při nasazení Ext4 obvykle skončil s hromadou souborů v adresáři /lost+found. A to ani zdaleka nešlo o diskové pole v řádech TB.

[Dramon]

Taky se mi to občas stalo, ale to mi kupodivu nevadí.
Víc mi vadí, když skončím úplně bez dat, nebo s nulovou velikostí atp. Čehož se bojím u XFS, jak psal někdo výše.

Matně si vzpomínám, že jsem již před lety někde XFS na zálohy měl a po nějaké době používání jsem jej formátoval pěkně "zpátečnicky" na ext3....

[Dramon]

Tak ne, díval jsem se do mé dokumentace a zemřelo to tenkrát na tom, že mi nedoběhl xfs_check do konce. OS byl 32bit s 4GB RAM, swap 8+GB a disk 4.5TB. Padalo to na out of memory, což jsem na těch 32bitech neměl moc jak řešit.

Ještě pro vysvětlení:
Pokud mi nějaký soubor chybí, odmažu staré zálohy a pustím to odznovu. Nic se neděje, nejsou to primární zálohy, kdy bych potřeboval bůh ví jakou délku do minulosti.
Pokud se ale smaže vše, znamená to tahat ty data přes internet, což u 16TB prostě trvá.

[dustin]

Jo, ten xfs check RAM žere a na 32bitech to snadno mohlo dojet na limit.

[Pavel 'TIGER' Růžička]

Já osobně mám vyplou automatickou kontrolu pomocí fsck, při výpadku se server automaticky ukončuje a sleduji stavy disků, jakmile se dějě něco podezřelého, tak je měním. Občas pustím fsck manuálně a k překřížení souborů mi už roky nedošlo. Ale pravda, já mám jen 9TB.

[Dramon]

Plus mínus to mám stejně, ale rozšiřoval jsem pole a říkal jsem si, že než to resiznu, tak to zkontroluju.
Pustil jsem "fsck -n" a hlásilo mi to pár chybiček někde v kroku 3+. Tak jsem to debil pustil naostro a z pár chybiček jich bylo víc a hlavně se to již nenamountovalo a hlásí to problém s "ext2fs_test_block_bitmap". Což by se asi dalo opravit, ale fsck to neudělá, dokud nedojede celá kontrola do konce a to už právě trvá docela dlouho .

Použení pro příště je udělat LVM snapshot a když se to tak vysype, tak to raději zkopírovat na nově zformátovaný oddíl, než to kontrolovat.

[Petr]

Ptas se co si pocit do budoucna. Ext4 je mrtve, brtfs je alfa, xfs a jfs maji sve vyhody i nevyhody. U me pred lety nastala podobna situace, vyhledove jsem zacal rust co se tyce dat +-20 TB rocne. Ma volba padla tehdy na freebsd a zfs. Mam xx poolu v ruznych konfiguracich, nejvetsi pool ma 30TB dat v milionech (desitkach) malych souboru. Scrub na tomhle poolu trva vice nez den, po vypadku napajeni se pool mountuje necelych 15 minut a nasledny scrub na online poolu trva o neco dele. Disky pod tim vsim jsou sifrovane. Ram mam v kazdym storage 256GB. Jsou to nejake xeony, sas disky od wdc, ecc ramky. Mam vicero nodu, vicero lokalit. Replikace dat je pakarna ale staci. Zatim.

[Petr]

Sorry, tech souboru tam nejsou desitky milionu, ale jenom neco pres 2M.

[Andrej]

…brtfs je alfa…

Tohle má být omyl, překlep nebo obojí? Já tedy vím jen o Btrfs, který není "alfa" a používá se v mnoha "produkčních" systémech. Kde přesně je psáno, že je Btrfs "alfa"? V nějakém článku z roku 2009 to asi bude. Zhruba od roku 2011 mám všechna svá data na Btrfs, k naprosté spokojenosti. Checksumy, copy-on-write a vestavěný RAID (který po desetiletích marných pokusů konečně opravdu dělá to, co RAID slibuje) jsou natolik zásadní vlastnosti, že si bez nich těžko lze představit souborový systém vhodný "do budoucna".

[alkoholik]

Jenze nekteri od fs cekaji, ze se dostanou k datum rychle.

[lertimir]

No to máš tak. Někteří čekají od FS, že jim nahlásí chyby, pokud nastane nejaký problém mezi diskem a pamětí díky kontrole checksumu. Nebo potřebují COW pro snapshoty. A pak jsou tací, kteří si bez této funkcionality nedovedou současný FS představit. Rychlost pro ně je pak otázka peněz. Třeba tak že budeš mít HW pole se SSD na infinibandu. Ale na Ext4 si snapshot a checksum nepořídíš za žádné peníze. Pokud ti absence těchto vlastností nevadí, tak je vše OK a můžeš využít rychlejší FS. (Jsou i jiní, kterým nevadí absence vlastností, které má standardní POSIX FS a používají FAT32. A myslím, že by v dost testech dosáhl i větších rychlostí na stejném HW než linuxový FS.)

[Pavel 'TIGER' Růžička]

Také jsou lidé, kterým je jedno, jaký FS jim tam běží, hlavně, že to funguje. Pravdou je, že FS se vybírá podle jeho nasazení a ne obliby daného uživatele.

[Jendа]

Tento benchmark je zcela zjevně zfalšovaný a určitě k němu použili nějakou historickou distribuci, například Debian s prehistorickým jádrem 4.14 ve kterém btrfs opravdu mohlo být nepatrně pomalejší. Kdyby použili moderní distribuci s libovolným jádrem vydaným v posledních 50 letech, například 4.15-rc2, tak by věděli, že tam už žádné problémy nejsou. Dále je z naměřených dat (IOPS, propustnost) jasné, že používají SSD, čili write-only-memory, kterou by žádný normální člověk nepoužil na nic jiného než bcache. Kdyby použili kvalitní rotační disky, tak na žádný bottleneck nenarazí, protože btrfs jejich 100 IOPS a 180 MB/s naprosto bez problému pokryje. Obecně fakt, že si vůbec dovolili srovnat btrfs s archaickými filesystémy ukazuje, že si svých dat neváží a chtějí o ně přijít. Například když se jim stane silent data corruption, která se na každém desktopu stává minimálně 158742x za hodinu, tak budou žít v blahé nevědomosti, zatímco btrfs by je na to upozornil, teda pokud by kontrola checksum zrovna fungovala.<EOS>

rnn-andrej-gen finished, inference took 10.973 seconds. Memory used: 985 MB.

[Andrej]

Lidé, kteří dlouho šíří různé kraviny — zejména pak popírači nových technologií, od parního stroje až po Btrfs —, občas zabřednou do vlastních žvástů a fantazií tak hluboko, že přestanou vnímat realitu a papouškují stále dokola otřepané fráze.

Povědomí o silent data corruption člověk získá teprve tehdy, pokud má zkušenosti s dost velkými systémy. Vtipní jsou zejména ti mudrcové, kteří v životě viděli všeho všudy něco mezi jedním desktopem a jedním rackem, ale zaručeně vědí, že silent data corruption se jich netýká. (Přesněji, nic o tom nevědí, protože tam mají Ext4 a věří v zázraky.)

[Peter Golis]

Sklamem ťa. Silent data corruption som zažil napríklad aj ja, a to bez racku. Bolo to v domácom segmente. Disky mi bez vyhlásenia chyby prečítali bloky dát s nulami, pôvodne boli v tých blokoch nenulové údaje.

V práci sa to u nás rieši s technológiami ktoré sa nespoliehajú že samotné disky by mali mať crc na blokoch.

[Pavel 'TIGER' Růžička]

Oproti parnímu válčí BTRFS není novou technologií je to jen další FS, který byl později napsán, nic víc.

[2017]

Proc se parni stroj tak rychle rozsiril a chtel ho kazdy?

[Aleš Kapica]

Proto.

[pavele]

A že jsme hodně postoupili v těch technologiích, že?

Zastaralý, předpotopní parní stroj s nízkou účinností, kde by se dnes ještě mohl používat?

[lertimir]

Celkem postoupili. Účinnost moderních parních turbin v porovnání k účinnosti Carnotova cyklu nad vyměníky odpovídajích teplot není nijak moc špatná. (na rozdíl od pístových parních strojů.)

[Heron]

Tve pozor, aby ti nepraskla cévka

[Andrej]

Opravdu se dostanou rychle ke svým datům? Co třeba ke svým náhodně pozměněným datům?

Jiný benchmark dopadne třeba pro Btrfs o fous lépe.

"Výkon" v nějakém benchmarku není až tak podstatný. Otázka je, jestli srovnáváme srovnatelné technologie. Jak by asi dopadl Ext4 s CoW, checksumy, vestavěným RAIDem a dvěma kopiemi metadat? Inu, dopadl by na prdel, protože nic z toho neumí.

Kdyby byl Btrfs desetkrát pomalejší než Ext4, asi by to stálo za nějakou hlubší úvahu. Jenže on je Btrfs v některých bencharkových "disciplínách" srovnatelný, někde dvakrát až třikrát pomalejší a výjimečně tu a tam rychlejší. Otázka pak je, proč bych vůbec měl uvažovat o zoufalství zvaném Ext4 bez checksumů, CoW a opravdového RAIDu. Fakt to nedává smysl. Můžu si koupit rychlejší disk nebo SSD, ale ztracená data si zpátky nekoupím.

[k3dAR]

opravdovy RAID? BTRFS kteremu kdyz v RAID1 vypadne 1 disk ze 2, tak uz na to nelze(jeste nedavno neslo) zapisovat, to dava(lo) opravdu novy vyznam slovu mirror ;)

[Heron]

"Výkon" v nějakém benchmarku není až tak podstatný. Otázka je, jestli srovnáváme srovnatelné technologie. Jak by asi dopadl Ext4 s CoW, checksumy, ...

Asi tak. Srovnávají se dvě zcela odlišné věci a někdo z toho pořád chce dělat nějaké závěry.

[Jendа]

který po desetiletích marných pokusů konečně opravdu dělá to, co RAID slibuje

Mně RAID slibuje, že systém nadále funguje i při selhání jednoho disku…

[j]

Myslis s tim vadnym diskem? Specielne pokud se bavime o SW raidu?

[Jendа]

Samozřejmě. Prostě ho oflaguje za vadný a normálně dál funguje - buď dopočítává paritu (R5/6) nebo používá druhou kopii (R1).

[Andrej]

Omyl. Chvíli dopočítává paritu, ale pak spustí resilvering a zničí všechna data.

Tohle už jsem psal asi tak stokrát: Zastaralý RAID se vypořádá pouze s totálním selháním (tedy de facto odpojením) jednoho disku, nikoliv s poškozením dat (více či méně náhodným) na jednom disku.

[R]

Minule tu bolo, ze tato "feature" btrfs je uz fixnuta. Alebo nie? Skusat to nebudem...

[Andrej]

Zastaralý RAID ale tento slib soustavně porušuje, což jsme řešili zhruba desetkrát, že ano. Nějak ses na těch jednoduchých faktech zaseknul a už mě celkem unavuje opakovat to stále dokola.

Zkus na RAIDu, který není integrovaný s filesystémem, přepsat celý jeden disk nulami, jen s výjimkou bloků s rádoby-RAID metadaty. Pak se uvidí, jestli ten systém opravdu ustojí (jakékoliv) selhání jednoho disku. Nápověda: Ne, neustojí; po čase spustí resilvering a zničí všechna data. ZFS nebo Btrfs v RAID konfiguraci to naopak ustojí, tedy kromě RAID0.

[Jendа]

Zastaralý RAID se vypořádá pouze s totálním selháním (tedy de facto odpojením) jednoho disku, nikoliv s poškozením dat (více či méně náhodným) na jednom disku.

Tak ještě že scrub tohle odhalí. Ne, počkat, scrub nekontroluje všechna metadata. Tak zkusíme ten strom projít. Ne, počkat, to přečte náhodně jenom jednu kopii metadat a navíc to neumíme efektivně udělat když máme snapshoty. Fuck.

Zkus na RAIDu, který není integrovaný s filesystémem, přepsat celý jeden disk nulami, jen s výjimkou bloků s rádoby-RAID metadaty.

Proč bych to dělal? Proč místo toho radši nepřepsat kus paměti náhodnými daty nebo nespustit rm -rf --no-preserve-root /? Vybral sis jeden z žiliónu způsobů jak přijít o data, u kterého má zrovna btrfs docela dobrou šanci, že ho odhalí, a upnul ses na něj.

[Jendа]

(přesněji: scrub zkontroluje checksum bloku s metadaty, ale už nezkontroluje, že ta metadata dávají smysl, tj. třeba že to je pořád validní b-strom, že ty pointry neukazují třeba někam dopryč, že jsou pořád dosažitelné všechny soubory atd., prostě to co dělá fsck na ostatních filesystémech)

[honza]

Proč bych to dělal?

Protože přepsání jedné strany mirroru nulami nebo náhodnými daty je ve skutečnosti dost dobrý příklad toho, co se ve skutečnosti často děje. Obvykle je to nějaká varianta jednoho z následujících scénářů:

1) LUN, který je součástí mirroru někdo omylem připojí k jinému stroji, který na něj začne zapisovat.

2) LUN, který je součástí mirroru je vyexportovaný z nějakého inteligentního pole, které podporuje klonování LUN, různé snapshoty. No a "admin" se jednoho dne prostě uklikne a místo dalšího snapshotu udělá rollback, nebo si splete směr klonování...

Proč místo toho radši nepřepsat kus paměti náhodnými daty

Vytvořit prakticky nasaditelný (souborový) systém, odolný vůči tomuto vektoru je hodně težké, ale máte pravdu, bylo by krásné ho mít.

nespustit rm -rf --no-preserve-root /

Tak od toho jsou snapshoty, případně další věci jako immutable zony atp.

scrub zkontroluje checksum bloku s metadaty, ale už nezkontroluje, že ta metadata dávají smysl, tj. třeba že to je pořád validní b-strom, že ty pointry neukazují třeba někam dopryč, že jsou pořád dosažitelné všechny soubory atd.

Ano, předpokládáný model je, že souborový systém generuje správná data a ta se případně poškodí pozdějí (na disku, ale i v storage stacku, v transportu atd). U ZFS se předpokládá, že bloky se správným checksumem mají i správný obsah.

fsck u extN atp. musí kontrolovat konzistenci metadata sémanticky, protože nemá jiný způsob, jak ověřit, že jsou správná. To sebou samozřejmě nese mnoho problém - to že nějaký blok vypadá jako uzel b-stromu ještě nemusí nutně znamenat, že to je opravdu správný a aktuální uzel toho správného b-stromu atd.

Samozřejmě, že se může stát (a stává), že je chyba v kódu ovladače souborového systém, ta se ale hladá jinak a jinými nástroji. Když v produkci pomocí fsck zjistíte, že místo b-stromu ovladač vygeneroval graf s cyklem, stejně s tím už toho reálně mnoho nenaděláte.

[Jendа]

1) LUN, který je součástí mirroru někdo omylem připojí k jinému stroji, který na něj začne zapisovat.

Tady přesně dojde k té situaci, že jiný stroj zapsal na btrfs blok s validním checksumem, takže FS je nekonzistentní a nikdo se to nedozví, ne?

2) LUN, který je součástí mirroru je vyexportovaný z nějakého inteligentního pole, které podporuje klonování LUN, různé snapshoty. No a "admin" se jednoho dne prostě uklikne a místo dalšího snapshotu udělá rollback, nebo si splete směr klonování...

Opět, rollbacknutý snapshot obsahuje bloky s validním checksumem…

[Aleš Kapica]

1) LUN, který je součástí mirroru někdo omylem připojí k jinému stroji, který na něj začne zapisovat.

Tady přesně dojde k té situaci, že jiný stroj zapsal na btrfs blok s validním checksumem, takže FS je nekonzistentní a nikdo se to nedozví, ne?

Pokud vím, tak Btrfs není síťový souborový systém, takže by mne docela zajímaly bližší okolnosti, jak by k tomu mohlo dojít.

[honza]

FC, iSCSI, IB, atd. dříve klidně i paralelní SCSI sběrnice sdílená více stroji

[Aleš Kapica]

Ovšem v takovém případě se nabourá každý souborový systém, co není určen pro clusterové nasazení. V takovém případě máte použít Cephfs, GlusterFS, OCFS2 nebo GFS2. Pokud použijete pro takový účel FS typu ZFS, nebo Btrfs tak si vědomě koledujete o ztrátu dat a nic jiného si ani nezasloužíte.

[Jendа]

Ovšem v takovém případě se nabourá každý souborový systém

Celou dobu tu neřešíme, jestli se FS nabourá, ale jestli se na to přijde. U MD s „klasickým“ FS se na to opravdu přijít nemusí.

Pokud použijete pro takový účel

Prosím přečti si ještě jednou ~3 příspěvky před tvojí reakcí. Bavíme se o omylu, ne o záměrném použití.

[honza]

Zjednodušeně řečeno: ZFS je strom, jehož každý uzel (~ datový blok na disku) v sobě nese checksumy všech svých přímých potomků.

Pokud je ZFS aktivní, kořen stromu je v paměti (tedy i checksumy jeho dětí). Když chci projít strom, začnu v kořenu a podívám se, kde leží jeho dítě (blok), kterým potřebuju projít. Načtu ho z 1. disku v mirroru, spočítam jeho checksum a porovnám s tím, co mám uloženo jako očekávanou hodnotu v kořenu. Pokud checksum nesouhlasí, přečtu ten samý blok z 2. disku v mirroru a opět ověřím checksum. Pokud je to checksum tentokrát ok, rovnou přepíšu blok 1. disku obsahem z toho 2 (ZFS tomu říká self-healing). Teď mám v ruce zaručeně validní blok/uzel stromu, jehož kořen mám v paměti. Zase obsahuje adresy a checksumy svých dětí, takže zase zvolím jeden disk z mirroru, přečtu blok, ověřím checksum, případně přečtu odjinud a opravím atd atd dokud nedojdu do souboru, který jsem chtěl přečíst.

Pokud ZFS není aktivní a něco špatného se stane s některým diskem, je to trochu složtější, opět zjednodušeně řečeno: změny v ZFS probíhají v transakcích, při každé transakci se vytvoří nový strom (s novým kořenem), na discích tedy najednou existují stovky stromů (ne všchny jsou samozřejmě kompletní). Při importu (aktivaci ZFS) musím vybrat ten správný, tj. co nejnovější, ale současně nepoškozený a použitelný kořen. Pokud někdo "rollbackne" jeden disk, kořeny uložené na něm budou "starší" než kořeny uložené na ostatních discích, takže nejspíš nevyhrají v testu "novosti". Každý kořen ZFS stromu checksumuje sám sebe, což je takový rychlý test proti přepsání části disku nulami nebo nějakým nepořádkem, dál se testuje, že je z kořene správně vidět alespoň začátek stromu. Správně by bylo samořejmě potřeba ověřit dostupnost všech uzlů, to by ale trvalo neúnosně dlouho, takže se to dělá jen u opravdu hodně poškozených ZFS poolů.

[dustin]

Je vidět, že o tom něco docela víš. Díky moc za užitečné info.

[Jendа]

Díky za info. Furt nejsem moc přesvědčen, že může nastat situace 1 (RAIDy se proti připojení v degradovaném režimu docela brání a typicky je potřeba opravdu ručně potvrdit, že tam fakt chci zapisovat) a pro situaci 2 má MD taky časové značky. (čti: ještě se mi taková chyba ani jednou nepodařila :)

[dustin]

Degradované md raid1 provozuji zcela standardně (i root), používáme to pro replikaci zálohovacího serveru na offline záložní disky. S montováním není žádný problém a nevzpomínám si, že bych to někde povoloval. Mám to i na embedded x86 routeru, kde jsem ještě nedodal druhý disk, takže běží systém na degradovaném md raid1 (U_)

[Andrej]

Mám zahodit ext4…

Ano.

…a přejít na XFS…

Ne.

[cronin]

Táto rada vedie tak nejako do slepej uličky. Čo teda navrhuješ použiť a prečo?

[Andrej]

Btrfs nebo ZFS.

Protože je rok 2017.

[Pavel 'TIGER' Růžička]

Já osobně jsem zkoušel různé FS, v různých fázích vývoje. Nemám asi vyzkoušené nejnovější verze. Ale z různých důvodů jsem se vždycky vrátil k EXTx.

[Trubicoid2]

Xfs bych se nebál, xfs_repair je skutečně multithreaded, navíc se sám nepustí, samo se dělá jen rychlá kontrola při mountu (je to v jádře). Podle mě je xfs robustní a hodí se právě na obrovská pole s velkýma souborama.

[honza]

Doporučoval bych přejít na nějaký moderní soborový systém, např. ZFS.

Fsck (v ZFS světě se tomu říká scrub) na ZFS může taky nějakou dobu trvat, nijak zvlášť to ale nevadí, protože souborový systém je během scrubu namountovaný read-write a k datům je možné normálně přistupovat.

ZFS používá kontrolní součty, takže pozná, že jsou (meta)data poškozená.Díky tomu scrub nepadá do různých podivných nekonečných cyklů, ve kterých mají tendenci končit fsck pro UFS, extN a podobné systémy (což je možná to, co se stalo teď vám).

[vasek]

Jen pozor na to, že ani ZFS není všespásný. Ze všech FS co jsem kdy používal se mi ZFS poškodilo nejvíce. Když vezmu různé výpadky proudu, HW problémy s řadiči apod., tak třeba ext3/4 se dokázal vyhrabat i z toho, kdy se rozbitý HW raid 5 špatně několikrát poskládal, čehož výsledkem hodně souborů skončilo v /lost+found, ale FS to přežil i s většinou dat. XFS se mi rozbilo v minulosti hodněkrát kvůli výpadku proudu ... respektive hodně souborů vynulovaných nebo nešel FS opravit. Poslední dobou (RHEL 7) se mi to abych pravdu řekl zatím nestalo (musím zaklepat). ZFS se mi v minulosti rozbil tak, že ve FreeBSD nešel namontovat ani opravit (oprava končila pádem OS). Nakonec pomohla nějaké live distribuce solarisu a tajný přepínač -X u repairu při zpool importu. Vinou byl sice HW problém, který ale luxusně ZFS rozbil.

Btrfs osobně nepovažuji za něco, co by se dalo jako FS používat. S ním jsem už skončil. Na linuxu jsem ho párkrát zkoušel, ale po pár hodinách či dnech se to vždy rozsypalo (stačilo zapnout nějakou featuru jako kompresi aj.)...

[Aleš Kapica]

No, s takovou bych ti nesvěřil ani budíka. Taky by se nejspíš rozbil.

[alkoholik]

Naopak! Takove lidi je treba zamnestnavat jako testery.

[vasek]

To už mi pár lidí říkalo :) Jsem totiž "klikař", který z 10 výrobků, které koupí má 9 vadných. Poslední dobou docela často plním github s různými issues v různých projektech. Než něco nakonfiguruji, obvykle koukám do zdrojáků (dost věcí není dokumentovaná) a dotáhl jsem to tak daleko, že daný SW nemusím ani spouštět a už v kódu narážím na nějaké chyby, které by mi mohli vadit v provozu :)

[lertimir]

No pokud pravidlo pro používání výrobků je skutečně takové, že používání znamená test odolnosti, tak se není co divit. Protože používat komplexní file systémy (jako bezesporu ZFS a XFS jsou) bez toho, že si zajistím dost bezpečně, abych se na HW mohl skutečně spolehnout. Což výpadky proudu skutečně nejsou. Já třeba ted na jednom nepodstatném FS řeším nějaké neopravitelné chyby v btrfs srubu, ale vím že jsem si je v podstatě způsobil sám, hraní si s přetaktováním s paměťmi, které nejsou ECC může udělat chyby. (Podobně bych ZFS bez ECC pamětí asi nikdy nepustil na produkčním systému.)

[vasek]

Právě, že použití je v podstatě klasické. Většinou značkové servery buď za UPS nebo v data centrech se zálohovaným napájením. Výpadky proudu jsem zažíval či zažívám většinou na vlastním železe (desktop ...).

[pavele]

Taky jsem si při nahlášeném výpadku proudu říkal, že mám UPS.

Tak server měl UPS, ale baterka klekla 3 dny před výpadkem.

Takže jsem si otestoval tvrdý výpadek s virtuály na ext4 a xfs.

Vždy je třeba počítat s nejhorší variantou a nespoléhat na to, že:

- vždyť mám UPS, výpadek mi nevadí,

- můžu si dovolit fs, který má problémy při výpadku proudu.

[Pavel 'TIGER' Růžička]

Tou kleklou baterkou bych se moc nechlubil ... je to něco podobného, jako nesledovat stav disků. V dnešní době ale platí víc, než kdykoliv jindy že čím více záloh, tím více jsou data v bezpečí.

[Aleš Kapica]

Tak to máš teda pravdu.

[hydrandt]

Taky si rikam, ze asi ziju v nejakem alternativnim universu (nastesti).

[Odin]

Doporucuji btrfs. Umi snapshoty, je rychly a dostatecne stabilni. Provozuji nekolik let bez problemu.