ZFS vprasanja, za in proti, izkusnje

Postavim si en server, notri bi dal dva ali tri diske v raid.
Kaksna je prednost ZFS, pa kaksne so slabosti?

Najbolje iz osebnih izkusenj.

Se splaca zfs namesto mdadm pri dveh treh diskih?

Odvisno, kaj boš počel. ZFS je veliko več kot zgolj "mdadm", pri čemer verjetno misliš neko vrsto RAID polja in gor en klasičen datotečni sistem?

ZFS dolgoročno veliko bolj pazi na podatke.

mah to bo kak ext4 čist ok..

Dolgoročno shranjevanje na ext4 zagotovo v podatkih pusti napake. Koliko jih je, ne vem, ker ne morem vedeti.

xandros> Kaj bi kljucnega izpostavili, zakaj bi vzel rajsi zfs?

Tole preberi:

http://arstechnica.com/information-tech...

Kolikor blokov je spremenjenih od takrat, ko je bil narejen (plus en drobiž).

xandros je 10. mar 2014 ob 21:36 izjavil:

Torej snapshot je ful uporaben.

A lahko imam diske razlicnih velikosti?

V poolu ja. Samo če boš pa 320 pa 2x500G diska dal v RAIDZ boš pa dobil 640G array.

A RaidZ lahko naredim z dvema diskoma? Pa cez cas, ce bom rabil, grem na 3?

RAIDZ zahteva vsaj tri diske. Za dva diska imaš mirror način. Ne, RAIDZ ne moreš širit - lahko pa daš zdaj dva diska v mirror in potem dokupiš dva in ju daš v mirror ter v isti pool.

Em, kateri del "RAIDZ se ne da širiti" ni jasen? :)

Dokupiti moraš novo RAIDZ polje in ga dodati v pool, širjenja NI (razen če seveda vse skupaj podereš, sformatiraš in nanovo postaviš).

Priporočam ti, da se naučiš osnove terminologije in rihtanja ZFSa preden greš v nakup (poglej si kaj je ZFS pool, kaj je RAIDZ (ter RAIDZ2, RAIDZ3) in mirror način, ipd.) - da ne boš brezveze zapravljal denarja.

Tudi to piše v članku. Na začetku (praktično) nič, potem pa glede na to, koliko podatkov se spremeni.

xandros> Vprasal, ce se da kaksen raid sirit,

Širiš lahko Btrfs (in delaš praktično vse enako kot z md raid).

jype je 10. mar 2014 ob 20:50 izjavil:

Slabost je, da potrebuje ogromno pomnilnika za ogromno prostora, pa da ga je razmeroma enostavno pripravit do strahotne počasnosti z določenimi vzorci uporabe.

Prednosti so vse ostalo.

ECC pomnilnika. Kar za seboj potegne dodatne stroške pri izbiri ustrezne strojne opreme.

Če rabiš hiter datotečni sistem, pozabi. Ta bo skoraj zagotovo najpočasnejši.

Slabost je tudi to, da v primeru okvare (kar se dogaja redkeje, kot pri drugih datotečnih sistemih, a vendar...), ugotoviš, da nimaš praktično nobenega orodja za obnovo ali reševanje podatkov.

Dodatna slabost je, da boš za stabilno implementacijo moral vzeti bodisi Solaris (drago), naslednika OpenSolaris (zelo omejena strojna podpora) ali FreeBSD (klasičen UNIX in ne Linux). Ne glede na vse, kar pravijo o ZFS na Linux sistemih, sta obe implementaciji bolj tako, tako. Performančno in iz vidika stabilnosti/zanesljivosti.

Bistvena, če ne kar edina prednost ZFS je ta, da je to edini prosto dostopen sistem, ki ponuja možnost odkrivanja (ne pa nujno tudi odpravljanja) napak v podatkih, če seveda redno izvajaš preglede (scrubbing). To ne odpravi zahteve za varnostnimi kopijami, pomaga pa neprimerljivo bolj zanesljivo ugotoviti kdaj je prišlo do napake in je potrebno vsebino obnoviti iz varnostne kopije. Ostalo imajo tudi drugi.

Sam tuhtam, da bi presaltal na ZFS (iz XFS). Predvsem mi je vsec moznost popravljanja napak na podatkih in deduplikacija.

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

AndrejO> ECC pomnilnika.

Brez tega je malce bolj nerodno, a še vedno daleč bolj varno kot brez ZFS. ZFS "odkrije" tudi težave s pomnilnikom (kar pomaga samo toliko, da veš, da so podatki zdaj pokvarjeni - ne moreš jih pa popravit). Pri navadnem pomnilniku in običajnem datotečnem sistemu ne veš niti tega, da so pokvarjeni.

Prodajaš krivo vero. Brez ECC ZFS ne zagotavlja end-to-end integritete podatkov. Napake v predpomnilniku ZFS-ja ne bodo vedno odkrite - tudi single bit flip ne. Neodkrite napake v metapodatkih bodo zaradi načina izračunavanja kontrolnih kod v drevesu privedle do uničenja datotečnega sistema, saj bodo pri zapisu sočasno poškodovane vse kopije metapodatka (adijo smisel redundance). Orodij za nizkonivojsko obnovo pa praktično nimaš, razen, če poznaš strukture na pamet in ti delo z bitki na surovem disku ni tuje.

Pa da ne boš rabil meni verjeti na besedo: Vir

Od testiranega v14 do trenutno aktualnega v28 ali v34 se tega ni dotikalo, ker je sistem namenjem strežnikom, kjer je ECC tako ali tako edina možna izbira.

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

AndrejO> ZFS ne zagotavlja end-to-end integritete podatkov.

Ne. Zagotavlja pa, da ko boš prebral podatke in ponovno izračunal checksum, ki se ne ujema s shranjenim, obvestilo o napaki.

Nope, ne zagotavlja ti tega. Najprej si preberi dokument, potem pa razmisli še enkrat, če tvoje izjave držijo tako absolutno, kot jih izrekaš.

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

AndrejO> Orodij za nizkonivojsko obnovo pa praktično nimaš, razen, če poznaš strukture na pamet in ti delo z bitki na surovem disku ni tuje.

Hvala za praktično demonstracijo zahtevnosti obnove podatkov na takšnem sistemu. Sem mislil, da ne bo potrebno tako nazorno pokazati kako pomembna so orodja, ki pridejo prav takrat, ko posamezniki ignorirajo dobre prakse.

Sicer je pa običajno zaporedje dogodkov sledeče:
- Non-ECC pomnilnik.
- bit flip v metapodatkih
- kernel panic, reboot
- "The pool metadata is corrupted."
- Game Over.

AndrejO> Nope, ne zagotavlja ti tega.

Seveda ti. Saj sem prebral kodo. Možnost, da bo napačno zapisan blok imel pravilen checksum, ali pa da bo okvarjen checksum po napaki pri zapisovanju veljaven, je infinitezimalna.

AndrejO> Sicer je pa običajno zaporedje dogodkov sledeče:
AndrejO> - Non-ECC pomnilnik.
AndrejO> - bit flip v metapodatkih
AndrejO> - kernel panic, reboot
AndrejO> - "The pool metadata is corrupted."
AndrejO> - Game Over.

Drži. To je v splošnem znatno boljše od tega zaporedja, ki je še pogostejše:
- Poljuben pomnilnik
- poljuben način shranjevanja podatkov
- bit flip
- bit flip
- bit flip
- bit flip
- 5 let izdelovanja novih varnostnih kopij z neveljavnimi podatki
- "moji podatki so neuporabni!"

Preveč komplicirate... Model bo meu storage server z parimi diski, ne pa server farme..

Ja imel bi dva diska za storage.
Zdaj mi je mdamd ok, dam oba diska lahko kam drugam, in pridem do podatkov.
Tudi ce en crkne, dam novega,starega pa lahko se mountam in pogledam kaj.

Ta snapshot bi mi mogoce prisel prav.

Kolikor vas berem, je ta ZFS namenjen za bolj velike stvari.

jype je 11. mar 2014 ob 11:31 izjavil:

AndrejO> Nope, ne zagotavlja ti tega.

Seveda ti. Saj sem prebral kodo. Možnost, da bo napačno zapisan blok imel pravilen checksum, ali pa da bo okvarjen checksum po napaki pri zapisovanju veljaven, je infinitezimalna.

I call bullshit.

Trdim, da je tvoja zgornja izjava samo tvoj povezetek razumevanja delovanja kontrolnih kod, nikakor pa ne rezultat razumevanja kode, kaj šele znak, da si kodo res bral in razumel. Prej nasprotno.

Lahko pa seveda rečeš, da poznaš delovanje ZFS bolje od raziskovalcev, ki so svoja dognanja javno predstavili na konferenci USENIX in katerih raziskava je bila tudi večkrat citirana in v celoti izpostavljena kritični javnosti.

Citiram nekatere njihove lastne povzetke iz raziskave (na temo napak v pomnilniku):
"ZFS does not use the checksums in the page cache along with the blocks to detect memory corruptions."
"The window of vulnerability of blocks in the page cache is unbounded."
"Since the checksums are created when blocks are written to disk, any corruption to blocks that are dirty (or will be dirtied) is written to disk permanently on a flush."
"Dirtying blocks due to updating file access time increases the possibility of making corruptions permanent."
"For most metadata blocks in the page cache, checksums are not valid and thus useless in detecting memory corruptions."
...
"There is no recovery for corrupted metadata."
...
"In summary, ZFS fails to detect and recover from many corruptions. Checksums in the page cache are not used to protect the integrity of blocks. Therefore, bad data blocks are returned to the user or written to disk. Moreover, corrupted metadata blocks are accessed by ZFS and lead to operation failure and system crashes."

Sedaj mi pa reci, da se ti mojstri motijo, ti pa imaš prav. Glede na to, da me danes čaka še dolg dan, bi mi malo smeha zjutraj kar prijalo. Pol zdravja in to :)

jype je 11. mar 2014 ob 11:31 izjavil:

Drži. To je v splošnem znatno boljše od tega zaporedja, ki je še pogostejše:

In čisto nič boljše od zaporedja:
- bit flip
- nikakršne prijavljene napake ("Observation 8: The read() system call may return bad data.")
- 5 let backupa z napačnimi podatki.

Torej: ECC or bust.

Bistvena razlika je, da so ostali datotečni sistemi bust ne glede na ECC. ZFS pa v kombinaciji z ECC praktično ni bust. Brez ECC pa se lahko reklamno sporočilo end-to-end varnosti prečrta, ker bil prečrtan bistven element v verigi varovanja podatka.

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

AndrejO> varuje tudi pred napakami v pomnilniku
Nisem tega napisal. Pravim, da nanje zelo hitro pokaže - čeprav praviloma tako, da enostavno javi napako (in ne deluje več), kar je IMO veliko bolje, kot silent corruption, ki ga po zakonodaji tega vesolja vedno ujameš šele ko si že vse uporabne varnostne kopije prepisal s pokvarjenimi podatki.

ZFS brez ECC na takšne napake ne bo "hitro pokazal". Imaš celo verigo dogodkov v predpomnilniku, kjer to preprosto ni res in rezultat bo natančno ta zloglasen "silent corruption".

BTW, so kaki poceni bordi za ECC RAM in za poceni strojčke ?

A ni bil napovedan APU Opteron enkrat te dni ?

Btw, 16GiB ECCC palčke niti niso več tako pošastno drage. €130-150 ni nevemkaj.

Kako bo se tem na DDR4 ? Je tam ECC že vo osnovni opremi ali ne ?

Rajši se vrnite na vprašanje OPja, dr*anje s tem, kater FS je bolši pa v drugo tem..

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

AndrejO> "ZFS does not use the checksums in the page cache along with the blocks to detect memory corruptions."

Seveda ne. Mirno zapiše neveljaven blok.

Ampak ko ga naslednjič prebere, to vsekakor zazna. Verjetnost, da bo ista napaka v pomnilniku povzročila, da se neveljaven blok prebere brez napak, je praktično nič.

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.

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

AndrejO> ZFS brez ECC na takšne napake ne bo "hitro pokazal". Imaš celo verigo dogodkov v predpomnilniku, kjer to preprosto ni res in rezultat bo natančno ta zloglasen "silent corruption".

Kaj pomeni "hitro"?

Karkoli si ti sam definiral kot "hitro pokazal". ZFS ne varuje pred napakami v pomnilniku in verjetnost, da bo zaradi tega prišlo do silent corruption je enaka, kot pri drugih sistemih. Ker kontrolne kode pri tem dejavniku ne pomagajo nič, ne moreš govoriti o nekih "infitazemalnih" vrednostih. Kar je težava drugih datotečnih sistemov je samo to, da ne varujejo ničesar drugega, kar pomeni, da se k tej verjetnosti prištejejo še vse ostale verjetnosti pri katerih pa ZFS pomaga.

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

Prvič, ko boš blok poskušal prebrati. To je ponavadi pri poskusu ustvarjanja prvega backupa po napaki, ko starejši backup še imaš - za razliko od konvencionalnih datotečnih sistemov, kjer se bo prva napaka praviloma pokazala ob odpiranju dokumenta v aplikaciji.

Ne poznaš dejanskega delovanja ZFS. Tvoja izjava je osnovana na napačni predpostavki in je zato vsebinsko napačna.

Brane22 je 11. mar 2014 ob 12:20 izjavil:

BTW, so kaki poceni bordi za ECC RAM in za poceni strojčke ?

A ni bil napovedan APU Opteron enkrat te dni ?

Btw, 16GiB ECCC palčke niti niso več tako pošastno drage. €130-150 ni nevemkaj.

http://geizhals.eu/asrock-e3c224d2i-90-...
http://geizhals.eu/intel-pentium-g3220t...
http://geizhals.eu/kingston-valueram-di...

Skupaj verjetno pod 400 EUR s poštninami, brez diskov, napajalnika in ohišja. S tem pa dobiš spodoben mini računalnik z ne pretirano porabo, ki bo dober za NAS z ZFS ali pa brez. Količino RAM se lahko po potrebi poveča na 16GB, če bo res veliko diskovja in vključen dedup.

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.

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.

hojnikb> OPja ste samo še bolj zmedl.. Sj ok... debata je na mestu, če odštejemo zahteve OPja..

Ne, ni. OPja zanima, če je zanj ZFS primeren in kakšne prednosti mu prinaša. Z AndrejO se samo ne strinjava, kolikšna je verjetnost, da bo ZFS ujel napako v njegovem pomnilniku, če je ta brez ECC bitov.

Sem šel gledat okrog. Gre za X1100 in X2100. Prvi je brez GPU, drugi ga ima.

Edini ki se hvali z X2100 je Sun z nekim serverjem. O X1100 ni nič.

Se kaj ve kdaj to pride ven ?

Cisto v redu debata je.
Tudi predlogi za hw so zanimivi.