Názor ke zprávičce Chyba v OpenZFS 2.2.0, můžete přijít o data od Izak - Apple bych tam netahal. BTRFS se kopirovanim principu z...

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.