Chyba v OpenZFS 2.2.0, můžete přijít o data

Problem je aj ten, ze nie je celkom jasne (aspon cez vikend nebolo, dalsie updaty som dnes nesledoval) ci tuto chybu nema aj opensolarisova verzia v sebe.

Podle odkazu na Block Cloning feature na githubu je ta funkce zavisla na nejakem nastroji, ktery instruuje vytvoreni klonu urciteho rozsahu, pac je to takovy manualni user-space dedup.

Takze i kdyby featura byla povolena, ke ztrate dat nedojde, dokud neco nezredukuje bloky skrze specialni volani, ne?

Ano, ale to dělá třeba cp --reflink=auto. Ale pozor, od coreutils 9.0 je toto výchozí, takže vám to udělá i obyčejné cp.

Jinak se to dá využít na offline dedup třeba: https://github.com/markfasheh/duperemove

Nevite jak je na tom Proxmox? Pisou ze ve verzi 8.1 je zfs 2.2.0 s bugfixs z 2.2.1, ale cert aby se v tom vyznal, tech chyb bylo patrne vicero a v jake.verzi je co opraveno?

V 2.2.1 to jeste opravene neni, porad s tim bojuji.

Je to tak, ve 2.2.1 je to jen vypnuté, čehož dosáhnete i ve 2.2.0 pomocí zfs.zfs_bclone_e­nabled=0

Podle Phoronixu se tato chyba může vyskytovat i ve starších verzích OpenZFS (a nejspíš i při vyplém block cloningu), viz: https://www.phoronix.com/news/OpenZFS-Data-Corruption-Battle

27. 11. 2023, 20:08 editováno autorem komentáře

Prichazet o data je na ZFS normalni vec, nebot nema nastroje na opravu jako xfs_repair nebo fsck.ext4 ...

Ale tohle je jeste vetsi problem, zde ani nastroj na opravu integrity nepomuze, nebot soubory jsou z pohledu FS zcela spravne, to ze jsou tam jina nahodna data je irelevantni - konsistence je pro nej OK.

ZFS je vubec takovy divny, misto aby na pomalych discich delal deduplikaci procesem, tak ji dela inline a zere to silene RAM - ale proc to dela i na SSD discich ?
Treba NetApp na spindle discich podporuje deduplikaci jen jako schedulovany preces, HPE 3par pro zmenu vubec ;-) - ale NetApp i napr. 3par podporuje inline deduplikaci a kompresi na SSD discich, a to bez toho, aby si vse drzel v RAM - jak to dela netusim, teda asi tusm a u 3par/primera je to i videt - nova data proste nededuplikuje ;-) nejak si je oznaci, ze jsou to nova nededup data a kazdych rekneme 10-20 minut pusti proces, ktery jen ty nove bloky zdeduplikuje - tim, ze je mapa hashu na SSD, tak ji nemusi nacitat do RAM, nebot je to dostatecne rychle.

NetApp podobne bezel ina spindle disicich, tez porojizdel jen to, co se zmenilo, ale trvalo to mnohem dele - nebot v ramci provozu tomu dal nejnizsi moznou prioritu a tak se treba 1PB storage kde bezel hlavne vmware, takze kupa zmenenych bloku bezel klidne i 1-2 dny - tedy jsme to poustely bude jen pres vikend, nebo mensi netappy v utery a pres vikend - pak sjem presli na fullflash a tohle odpadlo - jo na spindle jsme kompresi nepouzivali - ta bezela zbytecne dlouho.

Cili ZFS NetApp zkopiroval blbe, presneji, zkopiroval jej v dobe, kdy NetApp jeste nemel inline deduplikaci a oni ji vyresili pres RAM, pritom stacilo dat na hashe dedikovane SSD disky a delat to podobne - kdyz to NetApp doresil a vedeli, ze maji opravdu velke storage a tak by to sezralo kupu RAM - ne ze by byl problem ji tam dnes dodat ;-) - ale vyresili to salamounsky a hlavne rychle - zadne zpozdeni pri zapisech a pak pomalu dodelat na pozadi co nejakou dobu - takhle genialni vyvojari z ZFS nejsou, hklavne ze ukradli wafl FS od netappu, nebot netapp to tak dobre a do detailu popsal - ze z toho vznikl ZFS i BTRFS - NetApp dokonce Oracle udal, ze mu to ukradli, nebot ve zdrojacich byly odkazy v komentarich na stranky z netappu - jak to dopadlo jsme nezkoumal.

Můžete tu běžnost nějak kvantifikovat?

Ztrácet data je běžné i na S3 ... když ukládáte víc jak 100 miliard objektů déle než rok. https://aws.amazon.com/s3/faqs/

Myslím, že jste neodpověděl na otázku:
"Jenom se zeptám, to IBM DS400 je SAN a ne DAS, že? Neumí ZFS sdělit např. hodnoty SMART jednotlivých disků a celése to exportuje jako nějaký LUN?
Já jen, že ZFS je dost explicitní v tom, že chce vidět přímo na disky, přesně protože různé řadiče RAID atd. mají tendenci lhát."
kterou jsem psal jako odpověď na Váš komentář pod článkem: https://www.root.cz/zpravicky/openzfs-umi-paralelne-synchronizovat-vice-objektu-zvysila-se-rychlost-zapisu/1131127/

IBM DS400 je celkem stary SAN, ano, nema tam zmysl delat z-raid, proste se da jen jeden disk - na nem se vytvori v OS ZFS - a vyzivat jeho snapshoty atd. nebot IBM DS400 snapshoty neumi, teda uami, ale jsou nepouzitelne, nebot zpomaluji praci, jsou neco jako jako LVM2 - tedy neustale presouva bloky mezi snapshotem.

Problem je ze i kdyz tohle diskove pole data neztrati a neznici, tak pri vypadku vam je klidne znici ZFS a uz jej nanamountujete.

I BTRFS se mi tohle nikdy nestalo, jednou chtel fixnout a kdysi davno chtel manualne zvetsit index pro metadata, nebot se nezvetsoval sam a rychlost se zpomalila tak na 1MB / sec - bohuzel tento parametr byl v te dobe nedokumentovany a slo to jen jako jednorazovy parametr pri mountu - dnes uz BTRFS funguje skvele, nepouzivam tam ale raid, nebot chci raid5 - i kdyz BTRFS tvrdi, ze kdyz dam metadata na vsechny disky, ze pak nebudu mit problem, nebot spadly FS pak nahodi zpet - ne netstuji to, doma mam tak sw-raid5 a na nem BTRFS - ZFS bych tam nikdy nedal, prave proto, ze jsme jej videl 3x zrouceny vzdy na nejakem dikovem poli nebo internim RAID - a vzdy pri vypadky a vsdy to byla chyba jen a pouze ZFS, nikoliv disku, nebo raid pole ci raid radice.

Nejsem si jistý, jestli Vám rozumím správně. Pole vypadlo, všechna data byla správně zapsaná, ale ZFS nějak magicky posléze data poškodilo?

Zkoušel jste provozovat ten samý workload na tom samém poli pod jiným souborovým systémem, který by při stejně náhlém výpadku data neztratil?

Není to náhodou tak, že data, která byla polem potvrzená jako zapsaná vlastně zapsaná nebyla, ale byla třeba v nějaké cache, která se při výpadku vyprázdnila, protože třeba bylo pole nastavené jako write-back místo write-through a nebyla osazená baterie na cache/ nebo byla vybitá? Není to náhodou přesně to, proti čemu vývojáři ZFS explicitně varují? Co vypisovalo ZFS v takové situaci za informace?

"Můžete tu běžnost nějak kvantifikovat?"

Clanku o ztrate dat na zfs (a naproste nemoznosti s tim cokoli delat) je i tady hned nekolik, takze ackoli to zcela jiste neni reprezentativni vzorek, vypovida to pomerne dost. Kolik clanku za poslednich rekneme 10 let je tu treba o extX?

A pokud vemu v podobnych intencich zminovene btrfs a R5, tak realita je ta, ze k poskozeni dat muze dojit v situaci, kdy se zapisuje a je zaroven odpojena elektrina, coz je stav, pri kterem dokaze data poskodit libovolny FS. Proto se pouzivaji UPS aby nenastaval.

Kdyz to zuzime na zcela vadnou implementaci, kterou zjevne nikdo neotestoval, kolik jinych FS se tim muze pochlubit?

> kdy se zapisuje a je zaroven odpojena elektrina, coz je stav, pri kterem dokaze data poskodit libovolny FS. Proto se pouzivaji UPS aby nenastaval.

A já myslel, že žurnálování se používá kvůli tomu, aby právě tento stav nenastával.

A výpadek elektřiny není jediný způsob, jak k tomu může dojít, může selhat i jiný hardware, nebo software.

A já myslel, že žurnálování se používá kvůli tomu, aby právě tento stav nenastával.

To je častý omyl, ale ve skutečenosti žurnál slouží pouze k tomu, aby bylo po výpadku možné filesystém uvést do konzistentního stavu velmi rychle. (Kdo pamatuje, jak dlouho mohla trvat taková vynucená kontrola trochu většího (tehdejšími měřítky) ext2, ví dobře, jak je to důležité.) Poškození dat žurnálování samo o sobě zabránit nemůže, ostatně se nezřídka žurnálují pouze metadata.

V kazdem filesystemu se tu a tam nejaka skareda chyba najde. To, ze vas nepotkaly a nevenuje se jim pokazde takova publicita fakt neimplikuje, ze nejsou. Projdete si commity v gitu - ale pozor, at se vam neudela treba nevolno ;-)

Ano, různé verze ZFS měly historicky různé chyby, někdy specifické pro určitou platformu. Stejně tak EXT4: https://www.root.cz/zpravicky/linux-4-0-2-trpi-selhanim-souboroveho-systemu-ext4/ a u XFS celkem nedávno třeba: https://www.root.cz/zpravicky/poskozeni-xfs-s-jadry-6-3-a-novejsimi/ a samozřejmě potom jsou tu společné bugy, které se týkají všech blokových zařízení: https://lwn.net/Articles/774440/
Myslím, že je při srovnání se ZFS fér zahrnout i několik dalších subsystémů Linuxu (do určité míry device-mapper, LVM), ale to je asi na delší diskuzi u nějakého nápoje třeba, pokud by nebylo žádné lepší téma. :-)

Samozřejmě EXT4 i XFS se těší obrovskému testování, mají možnost kontrolních součtů metadat atd. takže se jejich spolehlivost neustále zlepšuje. Podle všeho ale není běžné dělat u nich kontrolní součty dat, což může celou řadu problémů v systému obecně odhalit a je to něco, co ZFS dělá standardně a u EXT4 či XFS si to musíte vyřešit jinak/ na jiné úrovni. Vývojáři ZFS si na sebe ušili bič a nastavili si laťku spolehlivosti velmi vysoko a je pravda, že občas tuto laťku nepřekonají a potom je z toho právem haló.

Pokud bychom o strojích přemýšleli v rámci diskuze mazlíček vs dobytek (pets vs cattle https://www.theregister.com/2013/03/18/servers_pets_or_cattle_cern/) Na stroje, které spadají do kategorie dobytek bych řekl, že je v řadě případů smysluplné použít EXT4/ XFS. Pokud je nějaký server spíše mazlíček, tak se může vyplatit zamyslet se nad ZFS.

Zas dokolečka tyhle poznámky o NetAppu, HP 3PAR.. atd. pod každou zprávičkou o ZFS.

Ne. ZFS není NetApp, ani 3PAR appliance - už jsme si to vysvětlovali.
Jedno je open source souborový systém, co můžete přímo použít na X různých zařízeních s komoditním HW a různých operačních systémech.
Druhé jsou jednoúčelová zařízení s proprietárními souborovými a operačními systémy, které jsou vyvinuty pro konkrétním hardware. Tomu logicky odpovídá i návrh a architektura systému.

ZFS není zkopírovaný, ani ukradený WAFL, přestože v nultých letech probíhal patentový spor mezi NetAppem a SUNem. Co si vybavuji střípky z těch soudu tehdy, jak o tom bylo referováno v médiích. Tak tam byl v podstatě přímé použití IP, jak vy tvrdíte ukradení, nebylo prokázané (sdílení kódu, identické dat. struktury jako v patentech NetAppu atp.), dokonce některé věci SUN interně vyvíjel víceméně současně s NetAppem, přičemž pouze druhá generace WAFLu šla na trh dříve. Zbytek byly v podstatě obecnosti (např. užití CoW ve filesystému, zapisovatelné snapshoty). Ty sice v americkém pat. právu můžou z určitých podmínek hrát roli, při extenzivním výkladu se tím můžou konkurenční firmy držet v klinči a nebo třeba brzdit vydání produktu nebo se mezi sebou trollit, ale tady to v podstatě ty vzájemná obvinění skončila dohodou hned po převzetí SUNu Oraclem.
Nakonec ty patenty z 90. let, o kterých byla řeč, už jsou teď dávno vypršelé.

Takže ta vaše argumentace, že když nějaký produkt má odlišnou řešenou určitou funkcionalitu, nebo ji příp. vůbec nemá, je důsledkem toho, že je blbě zkopírovaný/u­kradený, mi nedává moc smysl.
Je to podobné, jako bych tvrdil, že APFS od Applu, který shodou okolností používá CoW a má snapshoty, je blbě ukradený WAFL, protože ten na rozdíl od APFS umí i další věci, třeba integrovaný RAID.
Nebo ad absurdum, že SQLite je špatně ukradený Oracle DB (oba používají SQL, který Oracle/Rational uvedl r. 1976 jako první), protože SQLite neumí, nevím, materialized view ;)

Chápu, že pro vás asi ZFS nebude to pravé ořechové, nebo s ním máte nějakou konkrétní blbou zkušenost. OK, taky dost zvažuji, kam použiji jako technologii a neexistuje nic, co by bylo ideální do všech použití - a samozřejmě jsou také věci, které z určitých důvodů používat nechci. Ale nějak nemám potřebu pak někam nesmyslně vypisovat pod zprávičky týkající se produktu, o kterém jsem se už rozhodl, a nebo rovnou trolit ;)

Apple bych tam netahal.
BTRFS se kopirovanim principu z NetAppu vubec netajil ;-)
Jde o to, ze byla kupa akademickych veci, jak COW snapshoty funguji a vsichni to vime, teorie rika, nemenit soucasne bloky, zapisovat nove bloky jinam, treba do snapshotu - nebo do stejneho prostoru - ale realne to u nikoho nefungovalo bez penalizace vykonu - ze vmware ;-)) - ktery sice tvrdi ze to nema vliv, fakt udela zvlastni soubor a vsechna nova data da do nej, ale realne je to jeden velky problem, zpomalovac - nebot pak musi byt ta mapa bloku, ktere jsou stare a ktere nove.
Jak to duelat efektivne vymyslel jen netapp, o princip cow vubec nejde, jde o to, jak markovat bloky, jak to ukladat a handlovat tak, aby to nemelo zadnou penalizaci vykonu - a to prave NetApp vyresil a dost podrobne popsal, nebot se chteli pochlubit jak jsou dobri ;-)

Ale muzu klidne vse vynechat a rict, ze jsme videl nekolikrat v ruznych konfiguracich, vzdy servery, vzdy ECC RAM, a at uz diskove pole (SAN) nebo lokalni na HW raid radicih - tech skutecnych, co maji svoji RAM a baterku - ze pri vypadku, velmi casto blesk, ktery shodil celou serverovnu - ale vyboj se na servery nedostal, nebo shozene jistice - tedy vzdy se jednalo o vypadek proudu a u nej se ZFS znicil tak, ze nesel opravit, nebot tvurci ZFS tvrdi, ze opravne nastroje nejsou potreba - podotykam, ze diskove pole i raid radic si svoji chache drzi na baterkach, takze to co OS synchronaizoval na disky ze svoji RAM, to tam bylo - problem jsou data, jenz nejsou zapsana - o tech vime ze jsou poskozena - ZFS i BTRFS teoreticky tvrdi, ze dokud nejsou data fyzicky na discich, tak se nezapise do tabulky, ze jsou konsistentni a nic se netsane - no jenze to jeme meli na DB taky, namountovalo se to jako SYNC a brutalne klesla rychlost, coz nas netrapilo, DB ma prece ram a redolog - btw. ani Oracle na to nespoleha a ma opravne nastroje na tablespace ;-) - to je jina story - kazdopadne jsme tim zakazali chache OS a co OS rekl, ze ma na disich tam skutecne bylo.
V realu jeste mame cache OS a tak logicky BTRFS/ZFS ani netusi, co ma discich a co si mysli ze tam ma, nebot OS mu trasparetne rekne, ze to tam ma i kdyz to ma v cache ;-) - a proto jak BTRFS tak ZFS muzou mit nekonsistentni data a je treba to nejak opravit - kdybyz ZFS rekl, dobra, mi vzdy FS namountujem i s chybou a pak to opravime sami - jenze to se nestane, ZFS rekne, ze ma nekonsistenci a nejde namountovat, ma nejsou utilitu co to ma fixnout, ale ta jen bezi nekolik dnu, pak rekne ze je to OK a neni. - a nejak skupina lidi v praci mela s ZFS taky ty same problemy, na vmware virtualce - rikali ze uz taky obnovovali ze zalohy a zda nema lepsi reseni nez ZFS - jo ze nove pole podopruje kompresi a deduplikaci taky - byla to ale masina pro vyvoj, takze ne produkce, proto tam meli puvodne ZFS - uspora mista - produkci uz meli bud na nejakem SAN nebo NetApp - ktere tez dela deduplikaci a kompresi samo.

Cache disku samotnych je nastavena jen pro cteni - ale i tak je tam OS jeho RAM a taky zapisuje, ale tomu budem nejak verit, ze uz nedela cache pro zapis a ze nam nebude tvrdit, ze neco zapsal, ale v realu to tam jeste neni, jak to dela Linux

Uz jsme toho zazil hodne, oprfava sw_RAID, mazani josurnalu na ext4 - nebot kazdy novy zapis chyba a remount na RO - fsck nic nevyresil, jen to opravil a pak zase, tam slo o HW chybu vedel jsme o ni a pomohlo smazat jsournal a indexovaci strukturu FS na disku - trvalo to docela dlouho.

Na XFS nesla oprava xfs_repair - smazal jsem journal, nebot v nem hlasil chybu, tim padem musel oscanovat cely disk (presneji obsazene bloky, prazdne vynechava) a vytvorit novy journal - coz uz si udela sam, na ext4 jsme jej musel znova vytvorit rucne.

BTRFS uz jsme opravoval a uspesne, v hodne stare verzi jsme pres mount options jendorazove zvetosval metadata, nebot se sama nezvestila a zpomalil se na 1MB/sec - jako ze fakt ;-) - ale to uz bylo hooodne davno. - na BTRFS neverim jeho raid5 - ale pry kdyz si dam metadata ne do raidu, ale zduplikuji, doporucji na vsechny disky, protoze proc ne - pak kdyz spadne, tak jej pry bez problemu opravi.

Ja si RAID nejak zajistim, at uz SW na doma, nebo HW v praci - muzu mit SAN 3par i doma, ale dost to huci - na ZFS/BTRFS se mi spise libi snapshoty, reflinky a komporese s deduplikaci - deduplikaci a reflinky podpruje i XFS.

BTRSF treba umi to same co netapp - blokova replikace dokonce v rezimu snapvault i snap mirror - tedy bud dela kopii volumy/subvolumy 1:1 k danemu casu, nebo zachovava historii - a funguje to fakt dobre

takze na ZFS mi vadi, nerosiritelnost z-raidu - to bych nejak mozna presil, to ze mi zkolabuje a neoprtavim jej - to mi vadi nejvice a ze deduplikace zere neumerne mnozstvi RAM - proto mam radeji BTRFS - funkce snapshotu etc. uzm maji ZFS i BRTFS srovnatelne.

btw treba doma jsme delal upragde SW_RAID on the fly - z 8TB jsme koupil 20TB disky a jeden podruhem jsme vymenoval a delal rebuild - pak to roztahl - a svuj 1. NAs jsme resil tak, ze jsme udelal raid 5 na 2 discich (vim, SW_raid v linuxu umi prechzet a jo opravdu je pro raid5 min 2 disky a ne 3 ;-) 1 datovy 2 paritni - efektivne je to mirror, ale relne raid5) - no a az bylo potreba pridal jsme dalsi disk na 3 a expandoval a pak na 4 disky a expandoval - kupoval jsme disky podle potreby - spravne jsem usoudil, ze dalsi budou levnejsi ;-)

btw. firmy delal neco podobneho, ale jen se shelfy.

Ad posledni odstavec: je zbytecne delat R5 na dvou discich, protoze to vyzaduje plny resync, zatimco na R1 muzete vyuzit assume-clean, pokud na discich nic nebylo (jakoze jsou nove).

MD raid totiz umi migrovat libovolne raid urovne, takze zmena 1+1 mirroru na 2+1 raid5 je jednoducha:

https://serverfault.com/questions/830708/raid-1-to-raid-5-using-mdadm

Ja ted zvazuji zda dat R6 MD + ext4, nebo pouzit btrfs na presun archivu filmu - vim ze to bude zejma readonly vec a presun muzu udelat jako kopii kdyby se nepovedl ten btrfs R6, ale stejne me to vice tahne ke klasice.. navzdory nutnosti resyncu ktery bude cca na den (je to 6+2 x 5TB a zaplneno bude 27T z 30T)

Myslím si, že tvrzení, že se Linux tluče se ZFS/ BTRFS o to, jaká data jsou skutečně zapsaná na storage by chtělo asi nějak podložit. Nemyslím si, že jakýkoliv seriózní vývojář souborového systému by koncepčně připustil, že mu bude jádro někdy prostě bez chyby nebo další indikace odpírat jasnou výzvu k zapsaní dat. To, že na konci dne musí věřit aspoň diskům, že když potvrdily zapsání, že ta data taky zapsaná jsou, je věc jiná. Že v takovém případě některá zařízení (např. spotřebitelská SSD) můžou lhát, to je věc jiná, ale prostě vývojář souborového systému není všemocný a vševědoucí.

Kedze v spravicke bolo spomenuto aj FreeBSD tak pridaj aj oficialne stanovisko FreeBSD: https://lists.freebsd.org/archives/freebsd-stable/2023-November/001726.html

Tak ako som pisal hore, nie je teda este jasne, ze je dany problem aj v opensolaris verzii.
Do pozornosti by som dal info o block cloningu z tej spravicky.

A ted nekdo povidejte, jak je btrfs nespolehliva beta .... a R5 se vlastne vubec neda pouzivat, protoze to data doslova zahazuje ;D.

Tak to vypada ze vysla oprava ZFS :-)

https://www.freebsd.org/security/advisories/FreeBSD-EN-23:16.openzfs.asc
https://www.freebsd.org/security/advisories/FreeBSD-EN-23:15.sanitizer.asc

20231130:
14.0-RELEASE-p1 EN-23:15.sanitizer
EN-23:16.openzfs

Fix clang sanitizer failure with ASLR enabled [EN-23:15.sanitizer]

OpenZFS data corruption [EN-23:16.openzfs]