ZFS vprasanja, za in proti, izkusnje

Ja 8 x A57 core.

V bistvu so predelali "obstoječi" X1100.

Malo manj L2 po coreu, pa več coreov. A57 je verjetno totalen palček na 28nm, tko da verjetno ni blo problem počit par namesto Jaguar corea.

jype je 11. mar 2014 ob 13:04 izjavil:

AndrejO> ZFS ne varuje pred napakami v pomnilniku

Čemu si že drugič napisal da ZFS ne varuje pred napakami v pomnilniku? Saj jaz nisem nikoli trdil, da varuje.

Zato, ker mi dol visi za picajzlarsko razliko med "prepreči" in "opozori". Silent corruption je nekaj kar ZFS dopušča zato, ker ne preverja kontrolnih kod za podatke, preden jih pošlje zapisati na disk. Napak v pomnilniku ne odpravi in na njih ne opozori. Zapiše se napačen podatek s pravilno kontrolno kodo, uporabnik ne dobi nikakršnega opozorila. Če bi opozorilo bilo, bi bila tudi poškodba preprečena.

Konkretno si navedel:

jype je 11. mar 2014 ob 09:47 izjavil:

ZFS "odkrije" tudi težave s pomnilnikom (kar pomaga samo toliko, da veš, da so podatki zdaj pokvarjeni - ne moreš jih pa popravit).

Kar ne drži. Teh napak ZFS ne odkrije nič pogosteje kot drugi datotečni sistemi v istih okoliščinah. Kar lepo bodo ostale skrite.

jype je 11. mar 2014 ob 13:04 izjavil:

AndrejO> Nope, napača. Bit flip se zgodi, ko je podatek še v page cache in umazan čaka na zapis. Ko se ga bo ZFS odločil zapisati, ga bo prevzel, izračunal novo kontrolno kodo (stara je v tem konteksu samo okrasek) in pogumno zapisal napačen podatek z pravilno izračunano kontrolno kodo. Pri branju bo vse izgledalo OK. Silent corruption.

To je pa že stvar jedra in ne več ZFS, sorry.

Žal to je stvar datotečnega sistema in ne drugih delov jedra. Še zlasti takrat, ko datotečni sistem izrecno ne preverja kontrolnih kod pred zapisovanjem. Še zlasti takrat, ko bi ravno to preverjanje omejilo okno za nastanek napake na najmanjši možen minimum in se tako resnično približalo tvojem idealu "neskončno majhne verjetnosti".

Dejansko je problem jasen, odločitev tudi jasna, posledice ignoriranja dobrih praks pri uporabi ZFS pa tudi. Tvoje namigovanje na eno in potem vračanje na semantiko posameznih besed te omejitve ne bo odpravilo.

ZFS z zelo visoko verjetnostjo zagotavlja end-to-end integriteto podatkov samo pod pogojem, da se uporablja ECC. Če se ga ne, je verjetnost prikrite poškodbe podatkov podobna verjetnosti pri drugih datotečnih sistemih. To ni nekaj, kar bi bilo odvisno od drugih delov jedra, temveč je govora o zavestni odločitvi pri implementaciji. Že samo namigovati, da ZFS na sistemih brez ECC lahko "varuje podatke" ali "opozarja, če pride do poškodovanja" je narobe, saj posameznike zavaja in jim ne daje pravilne slike o tej lastnosti oziroma nujnih pogojih, da se takšno izjavo lahko poda.

Glede na to, da notranjosti ZFS-ja dejansko ne poznaš, pa za splošno izobrazbo samo še to:

ZFS bi se lahko implementiralo tudi tako, da se bi v page cache vpisalo blok s pravilno kontrolno kodo. Pri pisanju na disk se tako kode ne bi izračunavalo na novo, temveč se bi jo preverilo in na ta način odkrilo napako, če bi do nje v času hrambe prišlo. S tem se bi okno za možnost pojave neodkrite napake zmanjšalo iz celotnega časa, ki poteče od zapisa podatka v fizični pomnilnik, do njegovega prenosa na kontroler, na krajši interval, ki bi bil tudi navzgor omejen.

ZFS tega ne implementira, ker bi to reševalo problem, ki ga je že rešil ECC.

Kako naj bi bila naloga funkcij, ki skrbijo za upravljanje povezane liste prostih in zasedenih fizičnih strani v pomnilniku tudi varovanje podatkov, ne vem. To je namreč "servis", ki ga ponuja jedro. Vse ostalo počne ZFS sam (ARC, da ne boš predolgi iskal). Bodo pa verjetno vsi razvijalci jeder pozorno prebrali tvoj naslednji komentar. Jaz ga bom preskočil, ker bo verjetno znova na nivoju "nisem tega rekel".

Sicer pa se predhodno citirana raziskava (objavljena in peer reviewed) tvojimi poglede glede sposobnosti ZFS, da zazna, da je prišlo do napake v pomnilniku, ne podpira. Če izbiram med tvojimi enovrstičnimi medmeti na eni strani, ter svojim znanjem in javno predstavljenimi raziskavami na drugi strani, mi ni potrebno preveč razmišljati. ECC je poceni in ti rad zavajaš.

ZFS "odkrije" tudi težave s pomnilnikom (kar pomaga samo toliko, da veš, da so podatki zdaj pokvarjeni - ne moreš jih pa popravit).
Jih ne "odkrije". Get over it. To si napisal narobe in čas je, da greš naprej. Če postaviš hipotezo, da je to problem drugih delov jedra, tvoj problem. ZFS bi to lahko reševal, če bi za to obstajal interes. Ker imamo ECC, tega interesa pač ni, ker podvajanje nima smisla.

jype je 11. mar 2014 ob 15:41 izjavil:

AndrejO> Jih ne "odkrije".

Ja, jih. Kar se uporabnika tiče, jih odkrije, pa če se desetkrat postaviš na glavo.

Mislim, da je to trenutek, ko lahko rečem linkpls. Če nimaš tega javno objavljenega in preverljivega, potem nimaš nič. Kode nisi bral, raziskave tudi ne. Tvoja trditev je napačna.

jype je 11. mar 2014 ob 15:41 izjavil:

AndrejO> To si napisal narobe in čas je, da greš naprej. Če postaviš hipotezo, da je to problem drugih delov jedra, tvoj problem.

Žal mi je, zelo težko se sprijaznim s tem, da bi moral filesystem skrbet za integriteto podatkov pri prenašanju med jedrom in uporabniškimi programi, glede na to da nima popolnoma nobenega vpliva na te vmesnike.

Morda sem slabo opisal kje je omejitev. Vse, kar sem opisal se odvija v kontekstu jedra (pozabimo za nekaj časa na FUSE). In mimogrede, podatki se med jedrom in uporabniškimi programi ne "prenašajo". Večina teh operacij je danes zero-copy. Vse, kar se "prenaša", je sprememba deskriptorjev, podatki se ne kopirajo iz enega kosa pomnilnika v drugega.

Tudi na poteh, kjer se, je ta prenos v primerjavi s kasnejšim "ležanjem" podatka v predpomnilniku zanemarljiv. Tako, kot bi bil zanemarljiv čas, če se bi takoj po prenosu izračunalo novo kontrolno kodo in se podatek nato držalo v pomnilniku s pravilno kontrolno kodo, namesto da se jo izračuna šele sekunde ali minute kasneje, ko se ARC odloči, da je čas za odložitev na disk.

jype je 11. mar 2014 ob 15:41 izjavil:

AndrejO> Ker imamo ECC, tega interesa pač ni, ker podvajanje nima smisla.
Ko pa nimamo ECC, bit flipe ZFS odkrije hitreje in pogosteje.

Tistih v pomnilniku ne odkrije. Večina napak v pomnilniku se zgodi v času, ko podatek čaka, da bo zapisan. Kateri podatek, koliko časa in kdaj bo zapisan je v izključni pristojnosti ZFS. Če se zgodi bit flip v tem oknu priložnosti, potem ZFS napake ne bo odkril, kot je ne bo odkril tudi noben drug FS. Še enkrat si poglej raziskavo. Je lepo notri pojasnjeno. Ni ti potrebno brati kode.

jype je 11. mar 2014 ob 16:45 izjavil:

AndrejO> se med jedrom in uporabniškimi programi ne "prenašajo".

Ko tam stojijo, so del vmesnika med jedrom in uporabniškim programjem. Ko z njimi začne delat datotečni sistem, grejo najprej v transakcije, ki se zapišejo v dnevnik, že podpisane. Če so podpisani podatki pokvarjeni, datotečni sistem na to nima vpliva, drži. A ker se po tem dogaja še vrsta kopiranj, so možnosti za odkritje napake, pri datotečnih sistemih, ki podpisujejo bloke, znatne - pri ostalih pa neobstoječa.

Lep opis. Vendar pride do napake med tem ko pride blok pod nadzor ZFS (in ga ta vodi v ARC) in trenutkom, ko se ZFS odloči, da ga bo iz ARC poslal v smeri diska. Ta interval ni nujno kratek in tudi ni navzgor omejen. Če se v tem času pojavi bit flip, ga ZFS ne bo zaznal. Pred zapisom bo izračunana nova konktrolna koda, ki bo upoštevala flipped-bit in ta bo shranjen na disk.

Voila.

Silent corruption.

Enaka pot obstaja tudi pri drugih datotečnih sistemih, ki ne preverjajo podatkov in te podatke hkrati zadržujejo v fizičnem pomnilniku. Numerično je verjetnost s.c. zaradi napake v pomnilniku enaka, ker isti pomnilnik ne bo imel drugačne karakteristike napak samo zato, ker ga za svoje delo uporablja drugačen fs. Se bo pa verjetnost naključnih napak povečevala s trajanjem zadrževanja podatka v pomnilniku, če b.d. privzamemo, da so posamične napake neodvisni dogodki.

Glede na neko raziskavo, ki so jo v Google opravili pred mnogimi leti, podatki kažejo, da posamične napake niso čisto neodvisni dogodki, temveč korelirajo v pozitivno smer, kar pomeni, da ena zaznana napaka na modulu pomeni, da se bo zelo kmalu pojavila še ena (testirano na ECC modulih, kjer je na voljo statistika zaznanih napak).

Če te zanima lahko pobrskam za to raziskavo.

jype je 11. mar 2014 ob 16:45 izjavil:

AndrejO> Tistih v pomnilniku ne odkrije.

Pove pa ti, da je pomnilnik pokvarjen, ker je pokvarjen blok enako zapisan na vse lokacije.

V zgoraj opisanem primeru tega ne zazna. Kontrole, ki bi tam lahko bila, tam pač ni. Preberi kodo, če ne verjameš. Ni težko.

jype je 11. mar 2014 ob 17:02 izjavil:

AndrejO> Preberi kodo, če ne verjameš. Ni težko.
Ne predstavljam si, kako bi lahko datotečni sistem skrbel za podpisovanje teh reči in kakšen smisel bi to imelo, ECC gor ali dol.

OK, če se tebi ne da citirati virov ali brati kode, za zabavo:

Tukaj je funkcija, ki podatke, ki so trenutno vodeni v ZFS, pošlje v smeri diska.

Tukaj je klic, ki bi preveril kontrolno kodo (checksum, reci ji kontrolna vsota, če že moraš, ne pa podpis, ker tukaj nihče ne podpisuje ničesar).

Napisal sem "ki bi preveril", zato, ker je v funkciji ta pot onemogočena, če nimaš vključenega razhroščevanja. Tukaj.

Nato pa se izračuna nova koda v naslednjem klicu.

Poanta je, da se dejansko ne pregleduje, če je kontrolna koda še pravilna. To pomeni, da bit flip v pomnilniku ne bo odkrit. Pred pisanjem bo ZFS pridno izračunal novo kodo in ... kot tukaj rečejo "none the wiser" ... jo bo lepo zapisal na disk. Podatek pokvarjen. Nasvidenje v naslednji varnostni kopiji, ki bo prva pokvarjena.

Za nekoga, ki je tukaj namigoval, da ZFS kodo pozna, drugje pa, da je odprta koda dobra stvar, ker jo lahko vsak pogleda, se mi v tem konkretnem primeru zdi tvoje ravnanje precej leseno. Koda je javna. Omejitve so dobro dokumentirane že leta. Kogar to zanima, to že od nekdaj pozna. Izgovarjanje na neke vhodne podatke nima s tem nič. ZFS je dober za end-to-end integriteto (torej od vhoda do izhoda) samo na sistemih z ECC. Kjer ECC ni, smrdi podobno, kot ostali sistemi. Minus napake na diskih in vodilih. Te zelo dobro obvladuje, ker je, glej ga zlomka, načrtovan za njihovo obvladovanje.

Bom pobrskal še za tisto prej obljubljeno statistiko bitnih napak na strežnikih. Da se ne boš še na to nekaj izgovarjal, da je neverjetno ali kaj podobnega.

Vsaj trije.

AndrejO> Bom pobrskal še za tisto prej obljubljeno statistiko bitnih napak na strežnikih. Da se ne boš še na to nekaj izgovarjal, da je neverjetno ali kaj podobnega.

Ne pravim, da je neverjetno, človek božji. Pravim, da je neprimerljivo verjetneje, da bo ob napakah tiho konvencionalni datotečni sistem, kadar ni ECC pomnilnika.

AndrejO> Napisal sem "ki bi preveril", zato, ker je v funkciji ta pot onemogočena, če nimaš vključenega razhroščevanja. Tukaj.

Koda je tam, kaj bi še?

hojnikb> Jaz pa potrebujem nekaj, kar kešira drobne zapise (ki bi sicer totalno zabil kontroler) v nek buffer v ramu in jih dumpa po potrebi..

To (command queueing) je običajno naloga kontrolerja.

hojnikb je 11. mar 2014 ob 18:19 izjavil:

Jaz pa potrebujem nekaj, kar kešira drobne zapise (ki bi sicer totalno zabil kontroler) v nek buffer v ramu in jih dumpa po potrebi..

Če vztrajaš, lahko probaš ext3/4 full data journaling na external journal v ramdisk ;)
Sicer je mount -o data=journal,commit=30 odlična varjanta za maskiranje seek latenc na klasičnih diskih in sem jo s pridom uporabljal že 10+ let nazaj.

pegasus je 11. mar 2014 ob 18:25 izjavil:

hojnikb je 11. mar 2014 ob 18:19 izjavil:

Jaz pa potrebujem nekaj, kar kešira drobne zapise (ki bi sicer totalno zabil kontroler) v nek buffer v ramu in jih dumpa po potrebi..

Če vztrajaš, lahko probaš ext3/4 full data journaling na external journal v ramdisk ;)
Sicer je mount -o data=journal,commit=30 odlična varjanta za maskiranje seek latenc na klasičnih diskih in sem jo s pridom uporabljal že 10+ let nazaj.

Nekaj takega (keširanje vseh zapisov v nek ram buffer in potem dump na kartico) verjetno sploh nebi bla slaba ideja. Seveda to pride na račun slabeše integritete podatkov (powerloss, pa-pa podatki )

AndrejO> ZFS brez ECC ni v tem pogledu nič na boljšem.

Ja, je: Ne samo, da si me potolažil, ker sem kodo, ki preverja checksum tudi za dirty page, že videl, tudi kadar je izključena, je okno, v katerem se bit flip lahko neopazno zgodi, znatno zmanjšano - razen, kadar se zgodi v napačnem delu pomnilnika.

AndrejO> Ta pot je v funkciji privzeto onemogočena. Kaj bi ti rad? Dokazoval, da "cmp" občasno ne deluje?

Če se pogovarjamo o bit flipih, potem moraš s tem itak računati, kajne?

AndrejO> Do takrat pa lahko razmisliš zakaj ni nikakršne razlike med tem, da pride do bit-flipa v 1GB pomnilnika, ki ga ext4 zaseda 15s ali pa 1GB pomnilnika, ki ga ZFS zaseda 15s.

Ne strinjam se, da ta pomnilnik zaseda datotečni sistem.

jype je 11. mar 2014 ob 18:36 izjavil:

AndrejO> ZFS brez ECC ni v tem pogledu nič na boljšem.

Ja, je: Ne samo, da si me potolažil, ker sem kodo, ki preverja checksum tudi za dirty page, že videl, tudi kadar je izključena, je okno, v katerem se bit flip lahko neopazno zgodi, znatno zmanjšano - razen, kadar se zgodi v napačnem delu pomnilnika.

Izvoli biti potolažen. Samo vedi, da izgovori ne pomagajo, če ugotoviš, da imaš v varnostnih kopijah poškodovane datoteke. Na non-ECC sistemu te ZFS pred tem ne bo obvaroval.

Okno, mimogrede, ni zmanjšano. Preglej kodo in boš videl koliko časa lahko blok bivakira v pomnilniku, pod izključno kontrolo ZFS kode, popolnoma nezaščiten, ker se kode ne preverja.

jype je 11. mar 2014 ob 18:36 izjavil:

AndrejO> Ta pot je v funkciji privzeto onemogočena. Kaj bi ti rad? Dokazoval, da "cmp" občasno ne deluje?

Če se pogovarjamo o bit flipih, potem moraš s tem itak računati, kajne?

Na srečo mi statistika ni tuja. Tebi izgleda je. Verjetnost bit-flipa natančno določenega bita?

jype je 11. mar 2014 ob 18:36 izjavil:

AndrejO> Do takrat pa lahko razmisliš zakaj ni nikakršne razlike med tem, da pride do bit-flipa v 1GB pomnilnika, ki ga ext4 zaseda 15s ali pa 1GB pomnilnika, ki ga ZFS zaseda 15s.
Ne strinjam se, da ta pomnilnik zaseda datotečni sistem.

Tudi z gravitacijo se ti ni potrebno strinjati. To še ne pomeni, da jo lahko ignoriraš.

Verjetnost bitne napake v pomnilniku je definirana s časom in količino ter položajem pomnilnika. Če so čas hrambe, velikost hrambe in položaj hrambe v pomnilniku enaki, potem je verjetnost enaka. Ker ZFS ne preverja pravilnosti podatka tik preden ga pošlje na disk, je njegovo okno ranljivosti po času primerljivo z oknom ranljivosti drugih datotečnih sistemov. Tudi poraba pomnilnika korelira s količino razpoložljivega pomnilnika in datotečni sistemi, bodo v okviru svojih lastnih algoritmov, zasedli toliko pomnilnika za svoj predpomnilnik, kolikor ga ni porabljeno za druge podatke.

To pomeni, da lahko vzpostaviš primerljive pogoje testiranja med različnimi sistemi, če se omejiš na parametere, ki odločajo o verjetnosti pojave bit-flipa v podatkih. S tem, ko vzpostaviš (poljubne) primerljive pogoje in upoštevaš, da A in B ne preverjata podatkov pred pisanjem, ugotoviš, da je verjetnost neodkrite napake praktično enaka, ne glede na datotečni sistem, ki ta pomnilnik uporablja.

jype je 11. mar 2014 ob 19:01 izjavil:

AndrejO> Verjetnost bit-flipa natančno določenega bita?

AndrejO> Verjetnost bitne napake v pomnilniku je definirana s časom in količino ter položajem pomnilnika.

Halo? Niti približno: Verjetnost bitne napake v pomnilniku je odvisna od precej bolj "inženirskih" parametrov in nikakor ni statistično naključna.

Statistično naključna v kakšnem kontekstu? Verjetnost napake je zaradi proizvodnih toleranc med čipi različna, ravno tako se skozi čas uporabe spreminja. Vendar njene pojave ne moreš napovedati vnaprej. Kaj je torej "nenaključnega" na temu, da se pojavi napaka v bitu, če ne morem vnaprej napovedati kateri bit in kdaj.

Če je napaka "nenaključne" narave (za določen bite je p=1), se čip/modul zanesljivo izloči že med QA procesom. Malenkosti, da se število napak veča skozi čas uporabe (p se skozi čas spreminja) zate verjetno niso pomembne. Ravno tako ne močna korelacija med /verjetnostjo/ nepopravljive napake potem, ko je na modulu že bila zabeležena popravljena napaka (p se skozi čas še vedno spreminja).

jype je 11. mar 2014 ob 19:01 izjavil:

AndrejO> To pomeni, da lahko vzpostaviš primerljive pogoje testiranja med različnimi sistemi, če se omejiš na parametere, ki odločajo o verjetnosti pojave bit-flipa v podatkih.

Ja, ampak v praksi ta omejitev pomeni, da računaš narobe, ker je večina bitnih napak v pomnilniku trajnih.

To ne vpliva na to, da lahko enkrat uporabiš en sistem, drugič pa drug sistem na istem računalniku in boš pač dobil primerljive rezultate. Verjetnost napake na čipu se ne bo spremenila, če boš spremenil samo datotečni sistem, ki ga testiraš, ne glede na podležni vzrok napake.

Preprosto velja, da bom v bloku pomnilnika, kjer obstaja možnost napake z enako verjetnostjo zadel napako, če bom "poskušal" z alokacijo npr. 50% celotnega bloka enkrat in 50% celotnega bloka še enkrat. Ravno tako, kot je ta verjetnost manjša, če bom "poskušal" z enim bytom namesto s 50% bloka.

Edina spremenljivka, ki sem jo zameril, je razmerje med količino metapodatkov, ki je med različnimi datotečnimi sistemi zagotovo različno. Dvomim pa, da je teh za magnitudo več ali manj, da bi lahko rekel, da se bo napaka pojavila z bistveno večjo verjetnostjo v metapodatkih ali kodi, kot pa v dejanskih podatkih.

jype je 11. mar 2014 ob 19:01 izjavil:

AndrejO> in upoštevaš, da A in B ne preverjata podatkov pred pisanjem, ugotoviš, da je verjetnost neodkrite napake praktično enaka, ne glede na datotečni sistem, ki ta pomnilnik uporablja.

Izključno v primeru, ko je bitna napaka v resnici statistično naključna.

Nepomembno. Verjetnost napake se ne spremeni, če zamenjaš datotečni sistem. Če se bi, bi rad videl to raziskavo. Linkpls.

jype je 11. mar 2014 ob 19:01 izjavil:

AndrejO> Na non-ECC sistemu te ZFS pred tem ne bo obvaroval.

Že šestnajstič - tega nisem trdil. ZFS se bo na non-ECC mašinah z napakami znatno prej pritožil kot katerikoli datotečni sistem, ki ne preverja checksumov.

Če želiš še šesnajtič nazaj svoj citat.

jype je 11. mar 2014 ob 09:47 izjavil:

ZFS "odkrije" tudi težave s pomnilnikom (kar pomaga samo toliko, da veš, da so podatki zdaj pokvarjeni - ne moreš jih pa popravit).

Ne, ne "odkrije" jih. Ker jih ne "odkrije", te ne opozori. Ker te ne opozori, te ne obvaruje. Če nisi sposoben tega zaporedja prebrati v smeri: ne obvaruje te, ker te ne opozori, ker ne "odkrije", ti ne morem razložiti nič. Kadar ti to ustreza, nisi imun na bralno (ne)sposobnost, ki jo tako rad očitaš drugim.

AndrejO, a google ima kak tak fs, ki bi se zanašal na hw, ali še vedno zgolj podeseteri podatke, da je potem enostavno identificirati okvarjene in jih popraviti?

Bomo NSA vprašal :)

Pri ext4 se mi zdi da je opcija da pustiš plac za razširitve že pri inicializaciji.

Men se ta zadeva zdi primerna za majhen server.

Registered ECC DDR3 je precej počasnejši in ni ravno idealen za APUje, na serverju pa se za to ne bi smel sekirati.

Če imaš mali server in so ostale mašine v bistvu nfs4 klienti, je na serverju komot tudi kaj takega kot btrfs ali zfs. Če ne bi bilo problemov z novostjo in odsotnostjo orodij za čekiranje/repair.

pegasus je 12. mar 2014 ob 01:21 izjavil:

AndrejO, a google ima kak tak fs, ki bi se zanašal na hw, ali še vedno zgolj podeseteri podatke, da je potem enostavno identificirati okvarjene in jih popraviti?

To bolj ali manj ni point datotečnega sistema. Ampak prej različnih storage rešitev. Npr distribuiran object storage z razreševanjem konfliktov. Zfs je pač nek šmoren programja za upravljanje z diaki, datotečni sistem in še kaj ni pa vsemogočna rešitev za vse nevarnosti pri hranjenju podatkov. Niti ni namenjen nekim poceni in varčnim home nasom.

Zee zfs je podobno občutljiv na izpade elektrike kot xfs. Predvideva se da je vse skupaj poupsano. Prezistenca je zaradi keširanja in preverjanja do neke mere okrnjena. Tudi raid kontrolerji imajo dodatno baterijo, da se stvari izvedejo pravilno in do konca ali pa ovržejo.

noraguta je 12. mar 2014 ob 09:05 izjavil:

To bolj ali manj ni point datotečnega sistema.

To se da debatirat :)
Zame je point datotečnega sistema *hranjenje* podatkov, takih kot sem jih vtaknil vanj, v nedogled. Videl sem že mašine, ki so špricale random bitke naključnu po disku in takrat našel papir o iron FS, ki se obnaša trezno v takih situacijah. Ta papir je tudi potrdil moje takratne opazke, da je od fsjev na voljo reiserfs še najbolj robusten.
Moje vprašanje Andreju izhaja iz tega, da sem tudi sam reven kot google in doma nimam za eno zfs capable mašinco, imam pa kup stare šare, zato sem si spisal nekaj skript, ki delajo na file nivoju, vsak file skopirajo na tri stare pcje in potem na vsakemu lokalno periodično delajo sha in hashe primerjajo med seboj. Če so trije enaki, kul, če je eden drugačen, smo našli pokvarjen file, če so vsi trije različni, well shit. In to je moj poor's man zfs :D

Hayabusa je 12. mar 2014 ob 11:13 izjavil:

Tole bi znal biti zanimiv fs
ReFS @ Wikipedia

Mam na win2012r2 2 diska v mirror in refs. Zaenkrat dela bp in hitro. Za večja polja pa še ni zrel imo.

@jype: Kaj je torej tvoje priporocilo?

Se pravi, bo pri meni ext4 ostal mirno še kar nekaj časa.

Kdaj so že trobili da je "production ready", vmes pa že nevemkolikokrat potegnili ven take zajebe, da ti slabo rata.

Zadnja runda popravil kritičnih napak gre v kernel 3.15.
Fsck that.

MOgoče kaj bo iz tega tam okrog 3.20, prej ga niti pogledam ne.

Glede na to, da btrfs ne poznam pol toliko, kot ZFS... kako je s kontrolnimi kodami (checksums) pri temu? Nekaj sem povohal, vendar nisem prepričan, če sem bral načrte in dobre želje, ali pa dejansko stanje. Pa mi nekako ne sede, da se bi poglobil v (še en) datotečni sistem. TL;DR morda, če ga poznaš bolj intimno?

Oh, BTW. Stuck bit je ena varianta napake na čipu. Bolj tečna je ta, ki jo tedensko opazujem na svojem strežniku. Vsake toliko imam v določeni banki corrected error (ce). Ne vedno. Če poženem memtest ga povzročim ali pa tudi ne. Heba je, če imaš tako "pofentane" čipe in/ali module. Ko se napake pojavljajo na vedno vnaprej znanem mestu in z nekako predvidljivo frekvenco, vendar brez jasnega vzroka. :(

AndrejO> morda, če ga poznaš bolj intimno?

Nisem še skozi, ampak design doc ( https://btrfs.wiki.kernel.org/index.php... ) kar ok razloži, kako so si zamislili reči (in vsaj do zdaj nisem opazil večjih odstopanj v kodi). Zelo očitno je, da ne tekmuje z ZFS, ampak skuša izboljšati ext4 z dodatno funkcionalnostjo in ga narediti bolj robustnega. Orodja za reševanje podatkov so super (in že zdaj pridejo prav, haha).

AndrejO> Oh, BTW. Stuck bit je ena varianta napake na čipu. Bolj tečna je ta, ki jo tedensko opazujem na svojem strežniku. Vsake toliko imam v določeni banki corrected error (ce). Ne vedno. Če poženem memtest ga povzročim ali pa tudi ne. Heba je, če imaš tako "pofentane" čipe in/ali module. Ko se napake pojavljajo na vedno vnaprej znanem mestu in z nekako predvidljivo frekvenco, vendar brez jasnega vzroka. :(

Ja, sej tega mam tudi jaz ogromno. No, ne več dolgo, ker gre počasi vse v cloud, ampak biti so pri meni praktično vedno stuck, samo včasih se vanje napiše vrednost, ki je ves čas tam - flipanje bitov je pri meni več magnitud redkejši pojav, če sklepam po MCE eventih na intel mašinah.

Ales> Nisem čisto siguren, kaj se dogaja z btrfs. Malo sledim premikom (Oracle -> Facebook, itd.), ampak nekako se mi dozdeva, da enostavno rabi toliko in toliko časa, da dovolj dozori za uporabo in da je to dejansko več časa, kot je večina pričakovala. No, saj končno je zadeva zelo ambiciozno zastavljena, tako da mogoče je samo večina bila preoptimistična.

Drugačen je. Ni preveč podoben nobenemu do zdaj, še journalling ni, pa en kup funkcionalnosti je naklamfane gor (in dejansko lahko teče v userspacu).

Čez nekaj let bom javil, koliko podatkov mi je izgubil.

AndrejO> Samo, da ne bo pomote, nisem ciljal na "kozmično sevanje". To bi bilo čisto naključno, ne tako zelo dobro "lokalizirano" kot ga vidim sam.

Jaz tudi ne - lokaliziranost je ravno tista lastnost, zaradi katere lahko pričakuješ ponovitve napak, ki v resnici zmanjšajo možnost neodkrite nekonsistence. To (razliko med možnostjo odkritja resnično naključne napake in napake, ki sledi vzorcu, če se obe pojavljata enako pogosto) smo tule enkrat že izračunali na tablo, čeprav takrat nismo upoštevali, da alokacija strani v pomnilniku v praksi ni dovolj naključna.

Tudi ta PDF sem že prebral in ravno na podlagi tega sem si napisal orodje, ki mi DRAM ECC evente proži kot monitoring alarme.

Ravno zato sem tudi prepričan, da se zaradi teh (ponavljajočih se) bit errorjev sistem veliko hitreje sreča z nekonsistenco, kot bi se v primeru resnično naključnih dogodkov, ki so redki.

AndrejO> Bi uporabil tudi karkoli od AMD, ampak enota dela opravljena za vsak W tega nakupa ne opravičuje.

Ja, odkar je Intel začel prodajat procesorje s QPI, računice z Opteroni žal sploh ni več.