Vlákno názorů k článku
Nepoužívejte Bcachefs s jádrem 6.7 na více discích, hrozí ztráta dat
od Ergo_sum - Uprimne, kto ma odvahu nasadzovat podobne veci si...
-
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.
