Názory k článku
Nepoužívejte Bcachefs s jádrem 6.7 na více discích, hrozí ztráta dat
-
Z toho co vím, tak ZFS, Ext4 i Btrfs mělo bugy, kvůli kterým se ztrácela data. Tady jsou dva, co jsem našel hned:
https://www.theregister.com/2023/11/27/openzfs_2_2_0_data_corruption/
https://lwn.net/Articles/954285/Takže bez ohledu na to, co si napsal o nějakém syntetickém testování v Sunu, selhat může cokoli, i ZFS.
-
Ja nepisu ze ztrata dat nemuze nastat. To jsi mi vlozil do ust ty. Snazim se naznacit ze minimalizovat riziko ztraty dat u vyvoje FS je ukol ktery vyzaduje pomerne velke zdroje. A to jak hw tak lidske. Ok beru v potaz ze jsme testovali 2 hlavni hw platformy. To dnes x86 hipici teprve objevuji s ARMem co to znamena.
Samozrejme ze ZFS zvejkalo i interni nedulezita data plus testy u vybranych zakazniku nez se pustilo do sveta. Jenomze to nebyla five man show. Podileli se na tom lide kteri uz nejaky ten volume manager/fs vyvijeli.K odkazu - Sun tenkrat netestoval OpenZFS :-) Ty testy se delaji pro to aby se ta ztrata dat minimalizovala. Ty testy nejste schopni udelat ve five man show.
I veritas ve vyjimecnych pripadech ztracel data. Jenomze tam jsou drsne pozadavky na to co clovek musi mit aby se to dostalo o level vys. U nejvyssi podpory byla oprava do nekolika hodin kdy to preslo na nejvyssi prioritu pro vyvojare.Co lidi dost casto porad delaji za chyby:
- zamenuji troje implementace ZFS :-D
- absence ECC pameti - must have
- prepis zfs metadat v rezimu shared storage - ZFS nikdy nebyl shared filesystem. Nikdy ani tak nebyl designovany. V novejsich verzich se podarilo zacatek metadat nahodne popresouvat aby se aspon dalo obnovovat
- chybejici vicenasobne kopie metadat u kritickych systemu
- neupgraduji zfs datasety a pooly
- monitoruji sice disky, ale nemonitoruji stav zfs
- nadmerne pouziti deduplikace s kompresi
- pouziti deduplikace na velke objemy dat - na _zatim_ neni zfs stavene, mozna posledni updaty s offline. Pokud to potrebujete bezte za konkurenci -
Adam KaliszStříbrný podporovatelFast dedup by ty poslední body měl trochu pozměnit: https://www.ixsystems.com/blog/fast-dedup-is-a-valentines-gift-to-the-openzfs-and-truenas-communities/
Chtěl jsem Vás poprosit, mohli bychom se propojit (jestli mi třeba pingnete na email adam.kalisz [at] gmail.com ?)
-
Velmi, velmi dobre. Palec hore.
Ja este prilozim aj:
-totalne nevhodne volby hardware (ie "kvalitne hardware" RAID lol-"radice", ktore existuju hlavne pre poslabsie operacne systemy zacinajuce na W)
-kompletne retardovane storage architektury (zfs pooly z devices ulozenych na tom istom source na nizsom layeri eg diskove polia)
-ZFS NIE JE BACKUP (co je to backup ... to som nikdy nepocul)
-a retardovne nacvicovacky s poolami ("restore from backup", JE oficialna "best practice" na urcite situacie, ZFS commandy ju priamo ohlasia)Ako spravny sialenec co ZFS pouzivam od 2009 s FreeBSD 8.0 a mozem so vseckym hore plne suhlasit.
Zacinal som na 40GB zmirror (2x40) poole na 1Ghz celeron prcaku (nazov umyselne) s 1GB RAM. Kazdy clovek co dokaze pochopit co som napisal, si dokaze aj predstavit mieru masochizmu, ktorej som sa takto sam vystavoval. Povedzme, ze autocomplete na ZSH trval sekundu. Zaroven chapem, ze pre dnesnu mladez su to asi bezrozmerne cisla :D.
Ale stalo to za to. Napriek tomu ZFS valalo aj v podmienkach takychto extremnych sportov. A to ako oci.
Z anekdotalneho prieskumu medzi znamymi adminmi, co stratili pooly, mozem so 100% istotou povedat, ze secky straty co sa im stali, sa po dlhsich rozhovoroch ukazali ako cisty PEBKAC.
Z anekdotalneho prieskumu na internete, 99.9% strat je operator PEBKAC.
Videl som minimalne jeden issue thread na OpenZFS githube, kde chlapec prisiel s nejakym story ako sa ZFS pokakalo. Nastastie ma ZFS interny audit log commandov, issunutych nad poolom. Vyzvany borec tento audit log dokonca aj bez myslienkovo prilozil, dokonca verbatim, :). Z neho bolo jasne a krasne vidiet, ako bolo s poolom stenkrovane uplne inak, ako chlapec vo svojom story opisoval a strata bola zase PEBKAC. Po poukazani na dane fakty a vyzvu na jeho BS zrazu zostali len cvrcky, s issue autoclosed o par mesiacov.
Sam som ZFS videl prezit take sialene situacie, ze z ostatnych strojov, nije len z FS, by zostal salat.
Cize na zaklade tychto skusenosti, ZFS hejt beriem asi ako kricanie vypatlanych cajok. Daco v pozadi pristavu co sa bije o rybicky.
Ono aj ja, keby som teraz drzal hubu, tiez tu nikto ani nevie o tom, ze ZFS nejaky audit log vobec ma.
To totiz niesu informacie co nejaky franta mrkvicka dokaze predat lahkym blogpostom na vecerne citanie na styl "urobme si ZFS za 5 minut", alebo nejakym networkchuck videjom .
To uz je inde, v sun operacnych priruckach, oracle manualoch, v manualovych strankach atd.
Ono vacsina informacii v linux/unix svete je dnes uz len taky memeticky posturing. Vacsina modernych adminov je niekde medzi windows L2 a automechanikom co meni cele komponentove moduly. Ako sa vyskaldava xorg alebo wayland session od piky je pre nich black magic co "just works tm". A ked sa to rozondi, tak robia reinstall. Windows maniere.
Schvalne "to prove a point" co je to ZFS bookmark?
Ono dnes chce byt kazy cool, kazdy chce nieco povedat. A ved strata poolov je take sexi story. A tak vznikaju klebety.
Chlapec startil pool. Zle, zle ZFS! To ze staval jedno vdevovy pool (co uz samo o sebe je tuk tuk na hlavu moment a zaroven urgentny listok na psychiatriu) nad LD na hrackarskom HP SmartArray v RAID1 sa niekde stratilo v preklade :).
Pochybenia v uvedenom priklade ponecham ako domacu ulohu pre citatela.
19. 3. 2024, 17:37 editováno autorem komentáře
-
Adam KaliszStříbrný podporovatel
Myslím, že kolega Trident i já o zpool history a zfs bookmark víme. Bookmarky jsou prostě takové značky, aby se dal označit moment v čase a např. smazat daný snapshot, ale i nadále bylo možné vytvářet inkrementální balíky změněných bloků např. pro zálohy/ obecně send/recv. Je to za cenu vyšších IOPS, protože se AFAIK musí projít všechny transakční skupiny mezi bodem bookmarku a novějším bookmarkem/ snapshotem.
Nikdo neumí všechno. Důležité je podle mě, jestli se lidi snaží dělat věci nějakým způsobem dobře, nebo jim je všechno jedno. Když na mě vyskočí problém, kterému nerozumím, snažím se mu dostatečně porozumět, abych jej byl schopný vyřešit. Podobným způsobem se můžu ptát i dopředu, které problémy bych mohl mít, jak velké by byly a potom se zamyslet jak je řešit a jestli náhodou řešení nebude dražší než ten problém vynásobený jeho pravděpodobností.
Obecně bych byl radši, kdybychom si v diskuzi zde na Rootu nemuseli vzájemně dokazovat, jací jsme borci a co všechno známe. Sdílení zkušeností je jedna věc, ale podstupovat zkoušení zdejší osazenstvo asi nemá zapotřebí.
-
Myslim ze uplne na zacatku je dulezite si uvedomit ze ZFS svoji slozitosti neni FAT ani ext4. Ani kombo LVM/ext4. Pokud nemate zalohy a chcete to in-house opravovat je to pro vas spatne reseni. To same plati o jakkemkoliv slozitejsim FS nez je ext4 nebo ntfs. A to uz rada lidi netusi ze jak funguje ro u ext4 ci jak funguje zurnal u NTFS. A to jsou relativne jednoduche fs.
Ke kazde slozite technologii se vazou doporucene postupy a na co si mate dat pozor.
Renomovane data recovery firmy umi opravit i fatalne zhavarovany zfs. Pomoci nadstaveb nad zdg, internich vyvijenych nastroju, kontakty na stavajici a byvale developery atd.
To je ale uz ale reseni katastrofy a ne zakladni mechanismy prace se zfs.Na rootu v diskusich byl nejaky pomatenec co mel snad pod zfs jeste LVM a mdraid. Diskuse s takovym "tvorilem" je pak tezka.
Ja uplne pak chapu certifikace konfiguraci u komercnich alternativ. Nekdy je zakaznik naproste ale naproste... to slovo jeste nevymysleli. -
Skor som chcel pouzkazat na to, ze dnes ludi nezaujimaju detaily, kde je schovany ten diabol, a nie dokazovat co ja viem.
Pokail sa so systemom tak komplexnym ako ZFS neprplate roky tak ako my, mate len velmi vagne pochopenie vsetkych suvislosti, ak vobec nejake.
Tym padom akykolvek nazor vyjadrite je automaticky invalidny.
Problem je, ze vela ludi s takymito nazormi skusa, veci a potom ich doseru. Tak sa vytvaraju vselijake klebety. Ako, ze ZFS straca pooly, a podobne.
Podobne je na tom BTRFS. Napriek suvislemu commit streamu kazdy mesiac, je to z mojho pohladu tragedia. Ten FS smrdi. Ja osobne vtipkujem, ze pri BTRFS je najvytestovanejsia konfigruacia jednodevova VM :). Po masivnych problemoch v produkcii co sme zazili by som na to nedal ani logy. Napriek tomu mate armadu fanboyov, co to vzivote nepouzili na nic realne. Domaci server alebo notas neni pre mna realne nasadenie. BTRFS na uzasny hajp na to, aka polobeta to je.
Dufam, ze bcachefs bude na tom lepsie. Mam pren velke (cize v minulej dobe normalne) ocakavania.
31. 3. 2024, 15:45 editováno autorem komentáře
-
Se zfs jsem zacinal v dobe kdy vetsina z nas jeste obdivovala SVM( kteremu btw badal 3w mirror na tlamu) a veritas. Linuxaci si pousteli do kalhot z LVM a zurnalu u ext3. A muj tehdejsi zamestnavatel ZFS jaksi mezitim vymyslel. Jo a BSDckari si dekali ze Sunu srandu ze zkopiroval jaily :-)
Muzu se podepsat pod to ze vetsina problemovych aplikaci je spatne uz v zakladu. Fundamentalne. ZFS dokaze dat i takove zhuverilosti jako jeden disk v raidz s vyrazne horsi odezvou pripojeny treba pres iscsi... Jen diky online mereni performance jednotlivych disku.
Ne vsude je mozno mit DAS, JBOD a disky v tom samem racku.
Neni uplne spatne by design mit disky vystavene z nejake vzdalene storage z nejake skupiny . Jen idealne zvolit ruzne skupiny s podobnou charakteristikou vykonu. Jsou zákazníci kteri vam 1:1 konfiguraci proste nedaji. Ale tim jak mate LUNy ruzne ke storage rozhozene tak to ZFS docela dobre dava. -
Bryan Cantrill v nekolkych niekolkohodinovych videach specificky vysvetloval, ze ano skopirovali jaily, a to aby ich urobili spravne. A nazvali ich zony.
Cize OG unix komunita dobre vie, ze zony su jaily v prevleku, a podotykam velmi dobre urobene. Jaily su moja vasen, takze eventuelne som sa dostuvadoval az do bodu kde samotni maintainery jailov zacali brat inspiracie zo zon. Napriklad JID v jailoch alebo VNET jaily su priamo inspirovane zonami.
A potom tu mame dnes linux namespaces. Ako sa vravi niekedy privela je privela :D.
> Muzu se podepsat pod to ze vetsina problemovych aplikaci je spatne uz v zakladu. Fundamentalne.
Tak tak to je zhruba gist toho co sa so "zlym" ZFS deje.> Ne vsude je mozno mit DAS, JBOD a disky v tom samem racku.
Neni uplne spatne by design mit disky vystavene z nejake vzdalene storage z nejake skupiny.To nepopieram, specificky som narazal pooly s jednodevovymi vdevmi na hw raid (sak je to zdvojene) a ine podobne prasaciny.
Nemam nic proti potiahnutiu virtualnych LUN rovno do poolu. Pointa je aby devices boli vzdy RAW na block layeri, bez ziadnych translacii, duplikacii a nedajboze silent transformacii blokov (ako casto robi hw raid), a boli aspon (preboha ziveho) dve, teda v zmirrore. Ak sa aspon zmirrorovy pool niekomu vykoti chcem o tom pocut, ale este sa to nestalo.
Vzdy ked som zacal vrtat do "nehody", ako ste povedali, bolo to cele zle uz z principu.
-
Michal ŠmucrBronzový podporovatel
Tak hlavně záleží, jak to Ergo_Sum myslel. Jestli experimentální FS na důležité věci, tak samozřejmě.
Jinak poměrně hodně projektů ve svých úvodních fázích může znamenat určitou míru risku, ale zároveň je potřeba je testovat v různých situacích i dobrovolníky mimo samotných vývojářů.. a pak zapracovávat opravy, změny. Takže bych to rozhodně paušálně neodsuzoval a nesnažil se od používání vývojových verzí všechny rovnou odradit. I třeba BTRFS bylo označeno jako produkční (s výjimkou některých funkcí) asi až pět let po zařazení do jádra.
To jestli to riziko u konkrétního projektu stojí za to, je samozřejmě individuální věc a zvlášť u FS se tak trochu předpokládá, že uživatel ví, co dělá.Jinak v tomhle konkrétním případě bcachefs jsem také spíš skeptický nezávisle na těch nápadech a koncepci, co třeba autor popisuje v dokumentaci (paperu). Jak v případě XFS, tak ZFS a dalšími za tím projektem minimálně na začátku stála velká komerční firma, která zaměstnávala vývojáře/tým poskytovala technické zázemí, protože v tom viděla potenciál do svých produktů, nebo to řešilo to určitou potřebu. BTRFS se začal vyvíjet pod Oraclem, další výrazné posuny nastaly, když to začal používat Facebook pro svá kontejnerová řešení a hodně bugfixů přišlo s nasazením do distribucí (OpenSUSE, Fedora). A stejně i po letech tam dost věcí drhne (např. okolo multi device/RAID) - což spíš reflektuje to, na co to tyhle velké firmy používají.
Bcachefs je zatím reálně one man show s brutálním bus factorem (viz. těch pár předchozích eskapád s bcache zmíněném u jiné zprávičky) a placené jen komunitními příspěvky na Patreonu. Jestli to má šanci nějakou firmu, investora oslovit, aby se třeba rozšířil tým, zlepšilo testování, toť otázka. Já osobně bych na to moc nesázel. -
Jak jde čas, tak to vypadá, že fousatá EXT4 s kořeny v devadesátých letech minulého století, až na občasné excesy, zůstává jistotou pro obyčejného usera :-). Hnát se do minoritně používaného souborového systému znamená nutnost opravdu pravidelně zálohovat a počítat se ztrátou dat. Stále to říkám, jsou dva druhy lidí, ti kteří zálohují a ti, kteří o data ještě nepřišli.
-
Bohuzel ani to zalohovani nemusi byt zachrana - kdyz treba zvolite zfs/zfs nebo btrfs/btrfs kvuli tomu ze tam je send/recv .. a ono se to podela oboje.
Udrzovat ruzne technologie (diverzifikovat riziko) pak znamena ze jste degradovan na zakladni featury.. takze zas jsme zpet u preferenci klasickych FS.
-
Pokud člověk myslí zálohování vážně, tak zvolí nějaký ověřený filesystém. Však také na co mít zálohu na nějakém hyper-super systému, když se to potom nedá obnovit. Navíc záloha je záloha, tam nepotřebuju mít o tisícinu sekundy rychlejší přístup k souboru. Osobně preferuji EXT4, sice čas od času vidím nějaké srovnání, kde není tenhle stařeček kdo ví jak hvězdný, ale prostě funguje. Jasně pro webserver se asi nehodí, ale pro osobní počítač je to až někam a víceméně bez rizika.
-
Adam KaliszStříbrný podporovatel
Asi jsem první větu nepochopil, ale ZFS i btrfs jsou otevřené. Problém je, že běžný administrátor nejspíš nerozumí z hlediska kódu ani EXT4, ani XFS, ani ZFS ani btrfs a nakonec ani bcachefs.
EXT4 má svoje výhody a svoje úskalí (např. aktuálně https://blog.allegro.tech/2024/03/kafka-performance-analysis.html).
Disaster recovery na jiný souborový systém smysl dává, u záloh to nemusí být v určitých nasazeních možné, protože se to prostě nedá stihnout v daném čase.
-
Myslel overeny, ne otevreny. Proste "production ready, non experimental".
Jako tady ty problemy ze "kafka jede na ext4 pomalu", jsou takove echt cicoviny, ktere delaji dnesni decka protoze vubec nerozumi jak veci funguji - treba ze disky maji hlavicky, ktere je nutno nekam presunout, a tudiz je k dispozici nejake IOPS.
Pokud ta aplikace dela 300K iops, tak to asi normalni komp/ssd disk stejne neda. To neni problem EXT4 prece.
BTW ja mam ext4 implementovano po svem (v PHP), kvuli obnove dat.. neco jako btrfs/zfs se v rozumne dobe neda udelat a ani nevim zda maji nejakou normalni dokumentaci vyjma kodu.
18. 3. 2024, 19:25 editováno autorem komentáře
-
Adam KaliszStříbrný podporovatel
Oni nejedou na rotačních discích. V článku o tom sice není zmínka, ale předpokládám, že jejich systémy běží primárně na NVMe SSD. Tam 300k IOPS udělá v zápisu i jediné SSD. V článku na začátku se mluví o zprávách, které budou asi co do nároků na IO náročnější. Pointa článku ale je, že na stejném hardwaru bylo XFS pokud jsem správně pochopil i bez výrazného tuningu lepší, než vytuněné EXT4.
O btrfs nevím, ZFS má v dokumentaci docela rezervy. Jak psal kolega Trident, poměrně dost se asi dá zjistit ze zdb a dalších nástrojů. ZFS je prostě komplexnější systém, který umožňuje dělat na řadě míst mnohem silnější věci. Komplexitou bych řekl, že fér srovnání by bylo srovnávat ZFS spíše se stackem mdadm+LVM+EXT4+SQLite. Prostě ZFS dělá mnohem více práce a tedy dává i úplně jiné garance v běžném provozu. Na druhou stranu se to asi může i mnohem více pokazit, což se mě osobně zatím naštěstí nestalo.
-
Ale tak rozdil mezi xfs a ext4 muze byt o tom, jak casto se FS vlastne synchronizuje na disk do konzistentniho stavu (u ext4 je mount option: commit).
Nebyl nahodou takovej super rychlej FS (XFS?JFS?) ktery na disk zapisoval jen v dobre nalade - sice to bylo rychly, ale bez UPS jste byli porad v ohrozeni ze o nejake data prijdete pri vypadku napajeni.
-
V Sunu tomu zas az tolik lidi nerozumelo. To byli specialisti. Ja jsem se ztratil po prvni tretine prednasky jak pouzivat zfs debugger a dtrace pro hledani problemu v zfs aby bylo o cem prednaset. Ale tak jsem jenom blbej sysadmin/architekt co nici systemy a nema programovani jako hlavni napln prace. Mozna by to nekdo talentovany i dal napoprve.
Clovek s tim ale musi delat. Denodenne aby pochopil.Mit odladeny FS se pokrocilymi funkcemi je jedna z velmi tezkych uloh v IT. Zakerne je na tom to, ze to z vnejsiho pohledu pokud jste na tom nedelali vypada jako lehky ukol.
-
Az na ten drobny detail, ktery tu zaznel, ze mas vzdy nejakou zcela Omezenou konektivitu, a ta data potrebujes nejak v Omezenem case prenest.
Nemluve o tom, ze neni zaloha jako zaloha, a nikdy neresis 100% vsech okolostoicnoti ktere mohou nastat, jednoduse proto, ze jich je nekonecne mnoho, a to by znamenalo taktez nekonecne vysoke naklady.
Co myslis, jak funguje 90% vsech zalohovacich apps? Nj, delaji snapy. Jinak receno, na zalozni HW se prenasi prave a jen to, co se od minule "oficielne" = FS to nejak zaznamenal, zmenilo.
BTW: Nedavno jsem jednomu svemu zakaznikovi posilal milostne psanicko ... ve kterem jsem ho upozornil, ze kompletni obnova zaloh by trvala cca 10 dnu, v idealnim pripade. Rychlejs by to totiz na prislusnem HW neslo. S tim, ze realitu bych odhad na mesic, protoze ono se vzdy najde neco s cim se nepocitalo, co nefunguje, ...
-
To je jednoduche. Bud mi za to ta data stoji a nebo ne. Bud do reseni investuji a nebo ne. To same se tyka i zdroju a to nejen HW. Tj. nekoho kdo oddeli dulezita data od mene dulezitych. Kdo to vyjedna (nebo jak by rekl Prazak - vykomunikuje) u zakaznika. Data ktera muzou jit hned na archivaci a ktera maji jako mezistupen zalohovani. Jestli poridit temne vlakno nebo data vozit autem do trezoru.
Kdo naplanuje verifikacni behy a v jakem sledu. To je nezavisle na pouzitem FS. Zadny FS na svete neresi spravne zalohovaci procesy a dimenzovani infrastruktury.
Nedimenzovani backup site je jednim s dalsich prohresku. Zalohovani na jiny FS je level nizka az stredni investice.Dobrym kompromisem bylo reseni kdy daemon se byl schopen domluvit s backup serverem na tom kdy vyklopit buffery aby byla aspon nejaka konzistentni data , ktere bloky vyklopit na pasky a zaloha pak jela uz jen v rezii sanky,storage site a pasek. Nezatezovaly se koncove stroje. To je ale reseni od nekoho jehoz jmeno se tu nesmi vyslovovat.
19. 3. 2024, 10:13 editováno autorem komentáře
