Test linuxových súborových sytémov 2022 (diskuse)

[Max]

Do xfs se tlačí šíleně změn. RedHat na něm staví. Postupně se rozloučili s btrfs a začali hodně vyvíjet xfs, asi kvůli jejich Stratis. Nezkoumal jsem patche v jádře, jen tlumočím informace z jiných zdrojů.
Tím chci tedy říci, že hodně novinek bude zvyšovat pravděpodobnost nějakých regresí, nebo chyb. Držet se tedy něhjakého stable kernelu je tedy rozumnější.
Zdar Max

[AraxoN]

Jadro 5.15.32 je v gentoo označené ako stable. Kernel.org už takto označuje aj 5.17.6.

Ešte mi na testovacej zostave dobieha jeden test, potom sa pustím do hľadania toho xfs bugu.

[Max]

Stable je to, co má v sobě Debian nebo RHEL like :D.
Zdar Max

[Radek Podgorny]

skvele! ...diky za zverejneni (a samozrejme za test samotny)!

...uz se tesim na ssd verzi.

[henk]

+1

[anti-btrfs-fanatik]

Diky moc za porovnani!

Nezda se mi ten bit rot u btrfs - kdysi to bylo hodne spatne:

https://unixsheikh.com/articles/battle-testing-zfs-btrfs-and-mdadm-dm.html

Muzes to prosim dukladne overit?

Jo a docela zajimavy by byl test Stratis jak pise Max - chova se to "trochu" jinak nez cisty XFS, takze nelze pouzit vysledky mereni XFS.

[AraxoN]

Testoval som čisto len bit rot, teda preklopenie niekoľkých náhodných bitov na fyzickom médiu. S tým si btrfs a zfs poradili rovnako dobre, na jednotku. Btrfs o každom nájdenom prípade písal do syslogu, zfs nebol taký zhovorčivý, ale počíta sa výsledok a ten bol 100%.

Iné druhy porúch predmetom testu neboli. Násilné odpájanie diskov či simulovaná strata napájania nie je niečo, čo by som chcel skúšať. Predpokladám, že nedokončené zápisy budú problémom pre hocijaký súborový systém.

[: 00.000]

Vzhledem k tomu, ze dneska jede vsechno virtualizovane pod nejakym hypervizorem - tedy vcetne (predevsim?) pristupu k blokovym zarizenim - tak se domnivam, ze takove "virtualni vytazeni kabelu" je mozna i castejsi zalezitost nez bit rot.

Dalsi kupa zarizeni jsou natolik mobilni, ze lide u nich restartuji vytazenim kabelu ze zdi - tam pak ta konzistence v pripade nedokoncenych zapisu po vypadku napajeni hraje dulezitou roli.

Nezkousel jsem, ale krome ZFS (a mozna uz i btrfs?) log-based filesystemy (nilfs2, f2fs, ...) maji velkou sanci, ze naopak nebudou mit zadny problem s nedokoncenymi zapisy.

[Jendа]

Rozhodne zaujímavo vyzerajú jeho samoopravné schopnosti

No ale jenom v případě poškození dat na disku. Chyby v RAM (pokud nemáš ECC, nebo ti softwarový bug něco poškodil) vedoucí na poškození struktur FS jsou pro změnu fatální na rozdíl od jiných FS, protože u btrfs je fsck experimentální a u ZFS není vůbec.

To df used by bylo zajímavé dělat nějak podrobněji, protože nevím jestli jenom z used se dá vykoukat efektivita, může se třeba stát, že used+free < kapacita disku, ne? Takže ideálně tam potom zkusit zapisovat další data a koukat kolik jich tam doopravdy narvu.

Ten výkon při obsazování si myslím že bude dost ovlivněn i zdrojem dat - mnohem lepší by bylo generovat je synteticky.

[AraxoN]

Vyskúšal by som aj ďalšie failure módy, ale tie sa ťažko simulujú. Ako nasimuluješ chyby v RAM? Priložíš k serveru gama žiarič? A ako zabezpečíš rovnaké podmienky pre všetky testy? Mojou metódou som na každom z diskov "odhnil" práve 50 bitov, čo bolo dosť na to, aby to trafilo nejaké dáta, ale pravdepodobne nie metadáta či inody.

Df used som zaradil, lebo ma to takmer nič nestálo. Kým iné testy trvali rádovo minúty, tento bol hotový hneď. Beztak ide o číslo, ktoré reportuje samotný súborový systém. Keby tam hádzal prikrášlené čísla, nemal by som to ako poznať.

Všetkým týmto trom veciam (df used, fsck a bit rot) som nakoniec vo výsledkoch aj tak priradil nízke váhy. Išlo mi skôr o výkon v bežnej prevádzke.

Zdroj dát bol pre všetky súborové systémy rovnaký, čítaný z rovnakého nekomprimovaného archívu, ktorý sa nachádzal na iných dvoch diskoch (SW RAID1), ktoré neboli predmetom testu. Nemyslím si, že by tento zdroj dát spôsoboval rozdiel vo výkonoch jednotlivých súborových systémov.

[Mayhem]

Porovnavat reiser3 a btrfs je jako porovnavat dvouvalce a osmivalec. Srovnani ale jiste zajimave. Dekuji za clanek.

[AraxoN]

On aj ten dvojvalec má niekde zmysel, napríklad v motorke. Narozdiel od reiser3, ktorý zmysel nedáva už nikde.

[trekker.dk]

ext4 ... chýbajú mu checksumy

Dat. Checksumy metadat to má.

[AraxoN]

Áno, nevyjadril som sa presne. Otázka je, čo spraví, keď mu checksum metadát nesedí? Vie nejak požiadať SW RAID1, aby mu vrátil rovnaký blok, ale z druhého disku?

[trekker.dk]

Vie nejak požiadať SW RAID1, aby mu vrátil rovnaký blok, ale z druhého disku?

Tipnul bych si, že tohle rozhraní mezi filesystémem a blokovým zařízením momentálně neumí

[AraxoN]

To bola rečnícka otázka. Tiež si myslím, že to nie je možné. K čomu potom ale je taký checksum? Človek sa s istotou dozvie, že to má rozbité, ale pôvodný stav s tým neobnoví.

[Manažer]

Presne takhle hloupe se choval jeste pred dvema lety btrfs. Proste mel checksumy ale automaticky neopravil nic a vzdy pouze selhal. A dokonce tehda to bylo mnohem horsi, protoze se checksumy nekontrolovaly pri kazdem cteni (dnes se uz kontroluji?) ale teprve pri spusteni scrub (tzn. treba pouze jednou za tyden ci dele). Tehda clovek musel mit btrfs s RAID1 aby mel redundanci (ostatni "redundantni" RAID tehda bit rot opravovat neumely i proste, ze teoreticky by to mely umet).

Dle blogoveho zapisku si nejsem jisty, zdali btrfs byl provozovany v RAID1 nebo zdali ten bit rot byl detekovany az pri spusteni scrub. Nebo jak se to vlastne chovalo pri testovani.

Nejake detaily ohledne chovani aktualniho btrfs by nebyly?

[Manažer]

*redundanci jsem myslel "...rendundanci a scrub tedy mohl opravit data pokud nesedel checksum".

[AraxoN]

Išlo o btrfs na dvoch diskoch, s profilom RAID1 pre dáta aj metadáta.

Test prebiehal takto:

1. odpojiť fs (umount)
2. stopnúť raid (mdadm --stop)
3. bit rot (náhodne zmenených 50 bitov na jednom disku a iných 50 bitov na druhom disku (low level utilita vlastnej výroby, jazyk C)
4. spustiť raid (mdadm --assemble)
5. pripojiť fs (mount)
6. spočítať hash všetkých súborov (find /mnt/test -type f -print | sort | xargs md5sum > /tmp/hash.txt)
7. porovnať s referenčným zoznamom súborov a ich hashmi (diff)

V prípade btrfs a zfs samozrejme bez krokov 2. a 4., ale nikde žiaden fsck. Btrfs a zfs dokázali chybu nájsť a transparentne opraviť. Používateľ btrfs sa to dozvie iba zo syslogu, zfs o tom neinformuje vôbec.

[Peter Golis]

zfs o tom neinformuje vôbec

Už to vyhodili z výstupu príkazu zpool status ? Vídaval som tam pri podobných testoch.

[AraxoN]

Tam to možno aj bolo, ale ja som to tam nehľadal. On ten zfs je viac než len súborový systém a ja som nemal čas to celé študovať. Takže ďalej než po vytvorenie fs, mount a umount som sa s ním nezoznamoval.

[Manažer]

Dekuji za upresnujici info.

Takze vlastne byl otestovan ten jediny scenar, ktery jako jediny fungoval predtim (i kdyz tenkrat fungoval pouze napul; avsak nyni, zda se, funguje na 100% a nikoliv pouze napul).

Myslim, ze bez RAID1 (tzn. at jiz bez jakehokoliv RAID ci s jakymkoliv RAID jinym nez RAID1) to bude stejne spatne jako tenkrat - tzn. btrfs akorat hodi chybu cteni a to mozna pouze pri scrub a ne pri jakemkoliv beznem cteni. Nevi nekdo jaky je aktualni stav?

[Jendа]

Můžeš to pole sestavit degradované s tím druhým diskem. Pokud víš který z těch dvou disků to byl, tak můžeš blok snadno transplantovat z toho dobrého (dd ... skip= ofs=). Asi by šlo nějak i zjistit kterému souboru ten blok patří (inverzně to jde) a opravit přímo ten soubor.

[AraxoN]

Áno, to mi nenapadlo. Ale to už sa dostávame do režimu data recovery a všetko ostatné (bežná prevádzka) sa musí stopnúť.

[cbrpnk]

Ja mam povacsine JFS vsade. Nesklamal nikdy.

[AraxoN]

Najvyšší čas vyskúšať niečo iné. Alebo používaš nejakú unikátnu vlastnosť jfs, ktorú iné súborové systémy nemajú?

[Peter Golis]

ZFS má SCRUB, ten skontroluje konzistenciu zapísaných dát podobne ako FSCK u iných FS. Síce to beží na pozadí, ale odpamätá si kedy bežal posledne a koľko trval. Resp, má aj RESILVER pre kontrolu dát zapísaných od poslednej kontroly.

Alebo to už vyhodili?

[Jendа]

ZFS má SCRUB, ten skontroluje konzistenciu zapísaných dát podobne ako FSCK u iných FS.

Ne, zkontroluje pouze checksumy.

[Peter Golis]

A tie asi tak pokrývajú čo, nebude to náhodou konzistencia prečítaných dát a metadát ktoré boli pred tým zapísané aj s tými checksummami?

To je IMO viac ako robí fsck na zastaraných FS (ak nie sú kryté checksumami na doplnkovej vrstve).

[Jendа]

Ne, nepokrývají, já jsem třeba chybu dat na disku neviděl ještě nikdy (teda alespoň tam kde mám btrfs, takže bych ji detekoval), ale struktura se kazí v jednom kuse, IMHO jak HW chybami (non-ECC paměť) tak SW chybami.

[AraxoN]

To je zaujímavé... tá štruktúra sa Ti kazí na btrfs? Pri akej príležitosti? Strata napájania?

Ja sa pohybujem v serverovej oblasti a musím poklopať, že naposledy sa mi adresárová štruktúra rozpadla pred 15-timi rokmi, na reiserfs3. Podozrenie na bit rot sporadicky nájdem, aj keď mechanizmus vzniku zostáva neodhalený (t.j. neviem, či vznikol v RAM, na disku, alebo v aplikácii). Máme vcelku slušný sklad súborov, ktorý sme historicky prevádzkovali na RAID5 a ext4. K súborom sa zároveň do SQL databázy ukladajú ďalšie údaje, vrátane hashu (RIPEMD160). Na moje prekvapenie, keď som to jedného dňa nechal skontrolovať, v jednotkách prípadov to nesedelo.

[Jendа]

To je zaujímavé... tá štruktúra sa Ti kazí na btrfs?

Ano.

Pri akej príležitosti? Strata napájania?

Nevím, protože to nemá fsck co by člověk mohl pouštět po každém bootu, tak na to nepřijdu až dokud nenastane nějaký problém typu „nejde spustit postgresql“ nebo „rsync při zálohování nemůže přepsat soubor“. Napájení se ztrácí pravidelně (řešil jsem v poradně, ptal jsem se všude, stále bez úspěchu), RAM není ECC a softwarový stack je pochybný (nvidia blob + deep learning bastly v dockerech).

[Jendа]

Teda, má to fsck, byť se jako nemá používat, tak až ten FS vyrobím příště, tak asi nějak zbastlím aby se při každém bootu používal.

[AraxoN]

Tak, on fsck pri boote tiež nie je bohviečo, hlavne keď trvá dlhšie než pár minút. Pri reštarte servera na diaľku potom človek zažíva nepríjemné chvíle neistoty...

[Peter Golis]

A načo potom slúži scrub, v čom sa tá funkcionalita líši od chkdsk alebo fsck?

[Jendа]

scrub slouží na přečtení všech dat z disku a ověření checksumů, tj. jestli to, co se teď přečte, je to, co se tam předtím zapsalo. Od fsck se to liší v tom, že fsck kontroluje logickou konzistenci datových struktur FS (že stromy neukazují pointery kdovíkam - jeden způsob jak taková věc může nastat právě popsal RDa na Rootu, že právě všechny bloky označené jako obsazené jsou dosažitelné procházením adresářového stromu). fsck naopak nečte všechna data z disku (nečte datové bloky souborů).

[Peter Golis]

Tie checksumy overia či bloky (obsahujúce hoci aj dátovú štruktúru) neboli poškodené.

Ale súhlasím s tým, že SCRUB nie je FSCK, keďže SCRUB kontroluje a opravuje nielen metadáta, ale hlavne aj dáta na disku. Na to FSCK nemá, je zastaralý a mal by už konečne zomrieť.

Ale som rád, že si na ZPOOL SCRUB reagoval diskusiou o BTRFS CHECK. To bolo qejci.

[Jendа]

Máme novej PALM, podle paperu to vypadá nadějně, tak to otestujeme.

Tie checksumy overia či bloky (obsahujúce hoci aj dátovú štruktúru) neboli poškodené.

Jak si představuješ, že to opraví následující chybu:

• Poškodí se datová struktura v paměti (bitflip, race condition, out of bounds write jiným modulem)
• Zabalí se do bloku
• Blok se opatří checksumem
• Blok s checksumem se zapíše na disk
• Scrub přečte blok z disku (disk funguje v pořádku, takže blok není tiše změněn), zkontroluje checksum

[Peter Golis]

Máme novej PALM, podle paperu to vypadá nadějně, tak to otestujeme.

Tak ho implementuj ako modul do súborového systému, keď si sa s tým pochválil v diskusii o súborových systémoch.

Jak si představuješ, že to opraví následující chybu: (bitflip, ...)

Nijak. To neopraví ani FSCK, len to zabrúsi za cenu straty užívateľských dát. To opraví akurát tak ECC na špeciálnom HW s redundantným vykonávaním kódu a porovnávaním výsledkov. Alebo obnova zo zálohy.

[Jendа]

Nijak. To neopraví ani FSCK, len to zabrúsi za cenu straty užívateľských dát.

Zabrúsi = dostane FS zase do konzistentního stavu, aniž bych musel dělat odstávku na vytvoření nového FS a přelití dat tam a zpátky. Navíc na ZFS, kde fsck není, se o tom, že se tohle stalo, ani nedozvíš. Data se při tom občas ztratí (tak jako tak), obnovíš je ze zálohy, nebo se jedná o nějaké dočasné soubory na kterých nesejde.

[Peter Golis]

FS sa bud3 tváriť konzistentne, ale dáta ostanú v prípade fsck stratené.

[Jendа]

To v případě ekvivalentního poškození FS s checksumy taky.

[Peter Golis]

V dnešnej dobe je potrebné odhaliť aj poškodenie dát, nielen metadát.

[plostenka]

To bylo potreba vzdycky. A bud si ukladas data s ECC na aplikacni urovni, nebo veris FS, nebo veris RAID5/6, nebo...

[Peter Golis]

Takže buď veríš že ECC vykonáva korekciu, alebo veríš aplikačnej úrovni, alebo veríš FS alebo veríš RAID alebo neveríš že existuje Silent Data Coruption, alebo ...

Tvoj optimizmus by som chcel po mojich skúsenostiach mať.

[AraxoN]

Áno, a aj xfs má xfs_check. Vlastne ani btrfs nemá fsck, ale btrfs check, takže správne mal mať vo výsledku, že fsck "nemá".

Celý tento test nebol veľmi šťastný, pretože ak fsck trvá dlhšie, môže to znamenať, že je dôkladnejší a odhalí/opraví viac chýb. Preto som tomu nakoniec dal nulovú váhu.

[Peter Golis]

Čiže FS má nástroj na kontrolu konzistencie a opravu chýb, ktorý vie človek spustiť podľa vlastného uváženia, a samotný FS to robí aj sám pri bežných operáciách. Ale nemá FSCK. To znie tradične odborne a má to aj svoju logiku.

Ono, testík to bol pekný. I keď výber nástrojov a záver mi pripadajú také ako keby boli zaujaté. Skús ďalší test robiť s CPU ktoré má AES-NI, to sa zvyklo používať aj na checksummy. Čím novší typ checksum-u, tým vyššia výpočtová náročnosť a aj spoľahlivosť.

[Jendа]

Počítat checksumy AES-NI zní divně. Už dlouho, od SSE4.2, máme CRC32, a od někdy někde máme SHA.

[AraxoN]

Btrfs a zfs korektúry zjavne robia za pochodu. Rozhodne som im nedal žiaden čas na to, aby prebehol nejaký scrub celého disku.

Ďalší test bude na kompletne novom hardvéri a na SSD diskoch. Sám som zvedavý, či rozdiely budú vďaka tomu menšie, alebo naopak väčšie.

[Peter Golis]

NextGenFS síe robia kontroly a korektúry aj za pochodu, ale občas je rozumné vynútiť kontrolu alebo aj korektúru. Napríklad po fyzickom prenose zostavy s rotačnými diskami (možné škrknutie platne čítacou hlavou), alebo po dlhom vypnutí (pam. bunky zabúdajú, ak sa nepoužívajú). Mne trval SCRUB na lacnom 2T NB disku so šindľovým zápisom cca 7 hodín. Ale to mohlo byť spomalené aj tým, že OS nevedel o zónach na disku, a nemohol optimalizovať I/O požiadavky. CPU sa počas toho flákalo.

[mh]

A kdes nechal nejlepší souborový systém NTFS?

[AraxoN]

Nechal som ho tam, kde patrí.

[Peter Golis]

S tým súhlasím. NTFS je zastaralý, jeho nástupca ReFS by mal na tom byť lepšie. Ale z cenového hľadiska, ...

[ml]

Zastaralý je, ale podporuje ho kde co, a jenom zastaralost by asi neměla být důvodem házet ho do koše, nechť test ukáže nakolik je mizerný.

Já jsem po ntfs musel sáhnout pro uložení většího množství souborů (desítky milionů) protože ostatní systémy se někde u 10 milionů zasekly, bylo místo, ale nechtěly nic uložit. Pod linuxem to v ntfs sice taky tak vypadalo, ale stačilo strčit do počítače s widlema, přidat pár souborů a už to šlo i v linuxu než se vyčerpalo dalších 10 milionů. Nevím co to je za bariéru, windows se netvářil, že by měl být nějaký problém.

Uznávám, že jsem zvolil pitomý přístup, bylo to ale tehdy to nejjednodušší, ukládat soubory do adresářové struktury. Všimnul jsem si, že jiné aplikace pro stejný účel používají databázi, vznikne tak jeden velký soubor (+ nějaké ty pomocné) a ne miliony malých (fakticky zneužívám souborový systém coby databázi).

[ml]

Jinak jako vhodnou odpověď bych bral, že ntfs neni linuxový souborový systém a proto byl z testů vynechán. Tím by se to řešilo.

Je starý (k normálním lidem se dostal s dvoulitrama nebo xp na přelomu tisíciletí, ale ani tehdy nebyl nijak nový, roky předtím ho používaly nt), ale jestli je zastaralý to je otázka jiná (desítky jej stále používají jako základ). No při tom stáří by se zastaralost dala očekávat.

[AraxoN]

Je to tak, ntfs nie je linuxový súborový systém, preto som nad jeho testom ani neuvažoval. Už tak mi to zabralo dva týždne a potom ďalšie dva týždne som strávil riešením toho bugu, na ktorý som narazil pri testovaní xfs.

Aký je vlastne teraz stav podpory ntfs v linuxe? Sám si písal, že si ho musel masírovať z Windowsu, aby ďalej fungoval...

[PetebLazar]

A podle této logiky je ZFS linuxovým souborovým systémem? Pochází originálně ze Solarisu a vzhledem k licenci snad není(nemůže) být součástí jádra(Linuxu).

[AraxoN]

To je validná pripomienka. Skúsim sa brániť takto: zfs sa v linuxe bežne používa, narozdiel od ntfs. Častokrát je zfs doporučovaný v diskusiách aj tu, aj na roote. Používajú ho rôzne linuxové NAS-y.

Ale otestoval som včera aj ntfs, dám to do ďalšieho blogu...

[R]

Dakujem za pripomenutie, ze sa mam zbavit reiserfs3. Este zostaval na jednom serveri ako /var, tak som to vcera konecne preformatoval na ext4.

[Kooala]

Vyjimecne se podivam na abicko a hned takovy kvalitni blog post. Diky.

[Ivan Vecera]

Já nevím, ale 4 GB RAM pro ZFS mi příjde pro jakýkoliv setup málo resp. bych nikdy nedával ZFS na stroj s méně než 8 GB RAM. ZFS nejvíce vynikne na větších diskových polích, kde je i dostatek RAM. To neznamená, že jej nemužu dát na single disk stroj (sám jej používám na notebooku, ale s 32 GB RAM), ale ta paměť je fakt nutnost.

[AraxoN]

Bude ešte jeden porovnávací blog, s moderným harvérom. Až k nám ten server dorazí... Objednané pred mesiacom, ale ešte stále nemáme potvrdený ani len približný termín.

[AraxoN]

Predbežný dátum dodania: 27.6. (10 týždňov od vytvorenia objednávky)

[trekker.dk]

Hm, teď jsem se podíval do eshopu na jeden mikrokontrollér - jen ze zvědavosti, ještě nějaké mám. Skladem 0, termín dodání na sklad duben 2023. 10 tejdnů je sranda

[ml]

Arduino (AVR) a Raspberry jsou poslední dobou nedostupné (a co je dostupné stojí násobky cen, které pamatuju). Termíny dodání 50 a více týdnů. Je zajímavé, že PICů se to skoro nedotklo. Trochu podezřívám firmu microchip, že nás chce donutit přejít na picy. 10 týdnů je v tomto světle slušná dostupnost. Naštěstí pro své kutilské choutky mám nakoupeno, přecejenom nejedu v režimu just-in-time, ale pokud bych chtěl dělat něco nového, bude to problém.

Vzpomínám při poslední chipové krizi (cca 2010, také po jedné z krizí), jak mi kolega z jiného oboru (vývoj elektroniky) říkal, že na poptávky po součástkách dostává běžně přislíbené dodadí lhůty 60-80 týdnů. Tehdejší chipová nouze však nevstoupila příliš ve všeobecnou známost (automobilky měli tehdy čipy nasmlouvané).

[Jendа]

Arduino (AVR) a Raspberry jsou poslední dobou nedostupné (a co je dostupné stojí násobky cen, které pamatuju).

Zajímavé je, že Číňan AVRka docela má (jak na Ali, tak LCSC/JLC). Nevím jestli padělky -- popis vypadá jinak, ale to taky může být způsobeno tím, že je koupil Microchip.

[Petr Fiedler]

Super zápis, díky.

To jsem zvědavý na ten další test.

[PetebLazar]

V ramci Phoronix Test Suite existuje pts/pgbench (vycházející volně z TPC-B). Výhodou může být ověření reálnosti dosažených výsledků proti podobnému HW v databázi výsledků.

[AraxoN]

Ďakujem, pozrel som sa na to a zdá sa, že nastavia shared_buffers na štvrtinu veľkosti RAM a pgbench spúšťajú s parametrami:

pgbench -j $NUM_CPU_CORES -n -T 120 -r pgbench

Môžem sa tým inšpirovať.

[metazese stamezi]

Ještě prosím přidej do textu informaci o zásadní nevýhodě tohoto testovacího postupu:

Nemalá část testovaných souborových systémů byla testovaná v režimu téměř úplného zaplnění oddílu. V takových případech se souborový systém chová podstatně jinak a výsledky testu tedy zdaleka nereflektují běžný provoz, nýbrž patovou situaci, kdy dochází místo.

Každopádně díky - je to velmi poučné srovnání!