Vlákno názorů k článku ZFS nebo Btrfs: stabilita vs. podpora v distribucích od Ondřej Caletka - Trochu mě děsí, když je jako výhoda ZFS...
-
Ondřej CaletkaZlatý podporovatelTrochu mě děsí, když je jako výhoda ZFS prezentováno, že tři předchozí vrstvy − RAID, LVM a filesystém jsou nyní nahrazeny jedinou vrstvou všeobjímajícího filesystému. Mně teda mnohem rozumější připadá klasická třívrstvá koncepce, kde jsou vrstvy dostatečně jednoduché, takže třeba LVM jsem díky textovým metadatům schopen dát dohromady i ručně.
-
kolemjdoucí (neregistrovaný)
To byl před lety argument linuxové komunity proti zfs. A hle najednou ten třívrstvý "moloch" bastlí taky ala btrfs.
Ono totiž ta záruka konzistence a integrity vyžaduje ty vrstvy mít slité - mohu říct, že zfs používám už všude, kde mi záleží na datech, používat prehistorické fs, ketré prakticky umí jen trapný žurnál a které neuchrání proti bitrotu, to už je v 21. století na pováženou.
-
Ondra Satai NekolaZlatý podporovatelPredpokladam, ze maji na mysli bit rot http://en.wikipedia.org/wiki/Data_degradation
-
Jak často se to stává? Dlouhodobě (10+ let) si vedu si sha sumy svých dat (aktuálně pomocí SHA-512, datový objem kolem 4TB, postupně xfs, ext3, ext4 až na btrfs) a za celou dobu jsem nezaznamenal jediný poškozený soubor. Od roku 2010 používám BTRFS a scrub také nikdy neohlásil nesoulad mezi checksumem a daty. V produkci na storage xxTB také nikdy nic poškozeného.
ECC chybu jsem viděl jednu jedinou a to v L3 cache CPU. Na RAM nikdy (aktuálně něco kolem 500GB RAM na serverech celkem, vše pochopitelně ECC).
Tím neříkám, že ECC, checksumy nemají smyl. Mají. Jenže statistika ukazuje, že to není vůbec tak časté, jak se často tvrdí.
Pokud někdo má data z xxPB tak sem s nimi. Určitě to bude zajímavá statistika (1000x větší objem dat, než mám k disposici já, evidentně jsem pod hranicí měřitelnosti).
-
Filip JirsákStříbrný podporovatelNeviděl jsi na RAM ECC chybu (opravenou i neopravitelnou), nebo jsi neviděl neopravitelnou ECC chybu? To druhé by totiž nevylučovalo, že k překlopením bitu dochází, ale ukazovalo by to, že ECC je dostatečné na to, aby ty chyby dokázalo v drtivé většině případů opravit.
-
To první. Krom případu v L3 cache CPU jsem zatím neviděl žádnou jinou ECC chybu. V tom CPU byla opravitelná.
Viděl jsem vadný modul ram, kdy OS šel do kytek a IPMI zahlásilo chybu konkrétního modulu. Viděl jsem chyby v memtestech u nově zakoupených modulů (to viděl asi každý; proto se ostatně testují před nasazením do provozu), ale neviděl jsem ECC chybu při běžném provozu.
-
cthulhu (neregistrovaný)
"500GB RAM na vsech serverech dohromady"
512GB RAM obcas mame i per virtual. Pri takovem mnozstvi DIMMu uz semtam nejaky zfailuje (z meho subjektivniho pozorovani DDR3 drzi hur nez DDR2).
4TB dat je nic. Asi jako provozovat 1x4TB Seagate HDD a tvrdit ze je to spolehliva znacka, protoze me nikdy nezklamala..
viz. napr.
http://www.zdnet.com/blog/storage/dram-error-rates-nightmare-on-dimm-street/638
je ostudou Intelu, ze ECC umele zakazuje u consumer grade CPU, pritom to je par dolaru navic, koupit si unbuffered ECC DIMM..(viz. AMD 990X/990FX)
-
"512GB RAM obcas mame i per virtual."
Pěkný.
"4TB dat je nic."
Souhlasím, psal jsem, že to mám doma (8TB políčko). Na produkci máme xxTB (o řád víc). Předpokládám, že pokud máte 512GB RAM per virtual, tak už asi máte zkušenosti i s PB poli. Máte a můžete zveřejnit nějaké statistiky?
"je ostudou Intelu, ze ECC umele zakazuje u consumer grade CPU, pritom to je par dolaru navic, koupit si unbuffered ECC DIMM..(viz. AMD 990X/990FX)"
+1
-
cthulhu (neregistrovaný)
Jako statistiky umrtnosti disku? Pro maly byznys nezajimave, napr. EMC ma na discich vlastni firmware, disky z ruznych RAID group / poolu jsou jinak zatizene. Pak logicky disk ktery jede na 100% 24/7 se unavi driv. Disky se periodicky kontroluji na chyby (asi jako scrub v cronu:). Drtiva vetsina disku je kvuli performance v malych kapacitach (300-600GB FC 10-15K), tezko to pak srovnavat s 1-2TB SATA. Pokud mate tisice ploten, kazdy mesic jednotky disku umrou, zadna magie v tom (az na tu cenu:) neni. Co se plati, jsou spis velke RAM cache, skalovatelnost,vzdaleny dohled,online upgrade FW a "features" viz. klony, snadna replikace, dedup apod., nikoliv nejaka exkluzivita, ze disk "nikdy" neumre nebo ze je radove spolehlivejsi nez v soho. Nic z toho data nezachrani, pokud server bez ECC na LUN zapise bullshit, tak se tam taky mirrored bullshit dle ocekavani objevi:) Proto je treba data chranit jiz na urovni filesystemu a checksumu.
-
"Jako statistiky umrtnosti disku?"
Při našem počtu stovek disků (300-600GB 15k SAS) to dělá několik jednotek až (první) desítku disků ročně. Něco kolem 5% disků ročně (+- autobus). Přesnější statistiku zveřejnit nemůžu. Šlo mi ale o tu statistiku poškození dat nedetekovatelnou (pomocí samoopravných kódů) chybou apod.
"Co se plati, jsou spis velke RAM cache, skalovatelnost,vzdaleny dohled,online upgrade FW a "features" viz. klony, snadna replikace, dedup apod.,"
Tomu rozumím, osobně se mi příčí takové věci platit (bohužel je také platíme), vzhledem k tomu, že existuje rozumné OSS řešení. Zvláštní je, že není jasně viditelná hranice toho, co se nebude kupovat (například OS , za linux opravdu neplatíme :-D, webserver, database apod.) a co se bude kupovat (právě věci, které jste popsal). Přičemž obě skupiny jsou dostupné jak v komerční variantě, tak v OSS.
"Proto je treba data chranit jiz na urovni filesystemu a checksumu."
A samozřejmě zálohovat.
-
j (neregistrovaný)
Ja muzu nadhodit ...
Umrtnost 3,5" disku pri cca 80ti kusech neco kolem 1x/rok (vse 10/15k fc/sas)
Umrtnost 2,5" disku pri podobnym mnoztvi (sas) ... cca 3ks/rok.Jinak to taky vypada tak, ze cim novejsi zelezo, tim min disky vydrzej.
Co se ramek tejce, meli sme 1x opravitelnou ecc vadu, a dellu trvalo 3/4 roku (pri gold supportu ...) nez vymenili ten spravnej. Nejak sem nad tim jen kroutil hlavou, protoze hledat vadnej modul tak, ze vyhazu ze stroje moduly a zacnu testovat vsechny jejich kombinace ... lol (a tohle se delalo asi tak 5-8x, vzdy prakticky cely den). Kdyby vymenili ty moduly vsechny, tak je to muselo vyjit minimalne o rad levnejs.
-
Sten (neregistrovaný)
Jinak to taky vypada tak, ze cim novejsi zelezo, tim min disky vydrzej
To záleží, jak se na to díváte. Z pohledu množství dat (resp. URE) vydrží disky víceméně pořád stejně (no, trochu to roste, ale pomalu). Což je ale problém, když množství dat roste velmi rychle. Třeba s RAID 5 máte u většiny dnešních disků 50 % šanci na rozpadnutí pole při rekonstrukci 6 TiB; 12 TiB RAID 5 má už téměř jistý rozpad pole při selhání jednoho disku.
-
j (neregistrovaný)
Divam se na to jak sem psal - z pohledu poctu disku. Novsi zelezo bude prevazne na 2,5", ktery chcipaj proste vic, nez 3,5" i pri podobnych kapacitach.
A co vic, support je cim dal horsi. Pred 5ti lety kdyz mi chcip disk, tak mi za 2-3 hodky kuryr privez jinej, a za tejden si ve stejny krabici odvez ten vadnej. Dneska mi disk prijde za tejden, a jeste po me chtej, abych vyplnoval nejakej silenej formular s 10tistrankovym navodem ...
Tragedie je to prevevsim proto, ze pred tema 5ti lety do byl fc disk, kterej se posilal pres 1/2 zemekoule, dneska je to sas/sata, ktere si muzu zajet koupit do libovolnyho kramku v okoli za 15 minut.
-
trubicoid2 (neregistrovaný)
me jedna pamet delala ECC chyby priblizne ve stejnem miste, ale ne hned, az po ohrati a asi jednou za den
na memtestu toto nenajdes, i kdyz bezel nekolik dni
s memtestem je ten problem, ze kdyz mas ECC zapnuty, tak to mozna chyby opravi na pozadi a ty nic nevidis
no zkousel jsem memtest s ECC i bez samozrejme, nakonec jsem modul vymenil a pohoda
-
trubicoid2 (neregistrovaný)
>Jak často se to stává? Dlouhodobě (10+ let) si vedu si sha sumy svých
>dat (aktuálně pomocí SHA-512, datový objem kolem 4TB, postupně xfs, ext3,
>ext4 až na btrfs) a za celou dobu jsem nezaznamenal jediný poškozený soubor.tak jestli ty data jen lezi tak myslim vydrzi dost dlouho, kdyz je ale menis (+cow na btrfs) nebo zapisujes, tak pry zhruba 1 chyba na 10TB, jak zde zminuji na jinem miste
-
Izak (neregistrovaný)
Zalezi na discich, kolega mel 16 WD RE disku v RAID6 a videl silent datta corruprion.
RE disky, ale i bezne disky, kdyz zapisuji, delaji chyby, to je OK, zapise to znova, precte, kdyz precteni sedi, prohlasi to za OK.
WD vymyslel silent datat coruption, normlna eby mel disk vyhlasit I/O error, i kdyz pak blok nahradi rezervnimi, jenze WD ne, aby nestrasil lidi a nereklamovali mu disky, tak ten bolk vymeni potichu, nikomu nic nerekne a je to jev v SMART, stranda je, ze drive to tam bylo jen do vypnuti diksu, takze po rebootu se informace ztratila ... a to se vyplati.
WD omylem do nekolik RE edic omylem dodal desktopovy FW ... a tak se kolekovi poskodily data, prisle mu nato tripwire .... a to je duvod, proc jsem uvazoval nad BTRFS a ZFS i ja ... no popravde, nejdrive jsem uvazoval, ze si cracknu Ontap simulator a postavim si doma netapp ;-))) ... ale on ma 5% wafl rezervu v aggeragtu + by to pak neslo pouzit jako domaci server.
-
trubicoid2 (neregistrovaný)
no vysledku jo, predstav si, ze zakodujes data s jednou zmenou - ve vysledku bude zmen vic, ale to neznamena, ze se to nahodou nemuze tak na disku stat, ne? obzvlast kdyz ctes/zapisujes mnoho PB
"The SATA advertised bit error rate of one error in 10 terabytes is frightening...."
http://research.microsoft.com/apps/pubs/default.aspx?id=64599
-
ebik (neregistrovaný)
Proč by záruka konzistence a integrity to nutně vyžadovala mít slité? Jestli mám nespolehlivý HW, tak je jedno jestli mi selže přímo, nebo skrz LVM. Kontrolu integrity musím mít prostě v tom filesystému, tak aby přežil rozbití části toho blockdevice. Neříkám, že to půjde naimplementovat optimalizovaně, ale nevidím důvod, proč by to nemělo jít. (A pokud je potřeba znát topologii, tak Ext3 třeba obsahuje hint, jak velké jsou 'stripes' pod ním ležícího raidu. Pak záleží jen na nástrojích (mkfs a spol), aby takové hinty měly správnou hodnotu.)
-
ebik (neregistrovaný)
To máte pravdu. Na druhou stranu přesně tohle je celkem snadno popsatelná funkce: chci jinou variantu bloku X. Pokud mám blokové zařízení, o kterém vím, že má kontrolu chyb, tak přeci mohu rozšířit rozhraní (ioctl?) o to, že mi takové zařízení bude schopno poskytnout (postupně) všechny varianty (až 16 v případě 4 paritních disků, dnes se ale pokud vím používají nejvýše 2 paritní disky), a může (a nemusí) je seřadit podle pravděpodobnosti správnosti.
-
tom (neregistrovaný)
Na vrstvovém modelu v zásadě nic špatného není. Bohužel ale některé funkce nenaimplementujete nebo je nenaimplementuje optimálně, respektive tak jak je to možné bez vrstev. Zkuste s LVM udělat pár set snapshotů na ne úplně malých datech. Změřte jak dlouho vám to trvalo a kolik místa to zabírá. A pak to zkuste s btrfs.
-
Ondra Satai NekolaZlatý podporovatel
To je bohuzel pravda. Taky mi veci jako btrfs nebo systemd jdou filosoficky proti srsti... ale kdyz kouknu na to, ze mi funguji, tak pragmaticky neresim filosofii ale uzivam si, ze to dela, co ma.
-
Ondřej CaletkaZlatý podporovatel
To bude možná ono, že jsem nikdy pár set snapshotů vyrábět nepotřeboval :) Ale nenapadá mě, proč by v tom měl být nějaký zásadní rozdíl. LVM taky implementuje snapshoty jako COW, jen to dělá na blokové úrovni. Jediné, co mi na takto oddělených vrstvách vadí, je že snapshot z připojeného filesystému je v potenciálně nekonzistentním stavu. Ale i to by se jistě dalo nějak vyřešit − LVM by nějak filesystému řeklo: „teď se na okamžik zastav a dělej že jsi odpojen“. Možná už něco takového existuje, nehledal jsem to.
-
"LVM taky implementuje snapshoty jako COW"
Dneska už ano. Před pár lety ne.
" v potenciálně nekonzistentním stavu"
1. Snapshoty se dělají mezi dvěma zápisovými bariérami, takže fs by byl ve stejném stavu, jako při výpadku proudu.
2. Jenže není, protože LVM předává FS info o tom, že má ukončit zápisy.
Ať 1 nebo 2, nekonzistentní snapshot fs takto nejde vyrobit.
-
Palo (neregistrovaný)
Ale LVM nevie ci nad nim bezi FS ktory uz prirodzene robi ako svoju zakladnu funkcionalitu COW (btrfs) a preto to nevie robit tak optimalne ako to vie robit samotny btrfs.
To je samozrejme priklad, takych veci je viac, ked si viem riadit cely tok od disku az k sebe viem to urobit optimalnejsie ako ked sa to ma prevlakat cez N vrstiev, ktore nakoniec aj tak nerobia nic ine iba zabezpecuju aby sa dal zvacsit alebo zmensit FS (neberiem RAID level ten je obvykle HW)? ;-) -
JiRka (neregistrovaný)
Další věc jsou synchronizace pole - když na pár minut vytáhnu disk z mirroru v LVM a pak ho vrátím, trvá někdy fakt dost dlouho, než je volume zase synchronizovaný. ZFS naproti tomu jen překopíruje data, ktera se během té doby změnila, což je pro velké disky pod zátěží dost zasadní úspora času.
Taky se se ZFS nestane, že se na disk s daty omylem nasynchronizuje nepořádek třeba ze spare disku, ZFS podle checksumů pozná, která data kam patří.
-
snajpa (neregistrovaný)
Proc bys mel kdy potrebu davat dohromady neco, co se proste ani nikdy nerozbije? Ve smyslu, ano, u toho slepence si muzes prepsat metadata, ale kdyz se podivas na layout ZFS na disku, no musel by ses docela snazit to odtamtud nahodou smaznout. A kdyz jo, tak slepenec by podobnou operaci neprezil taky tak.
Nejak nevidim duvod zustavat u slepence, jsou to proste jenom umely myslenkovy konstrukty v hlavach lidi, co se storage delaji - kdyz ty koncepty smaznem z hlav, v realnym svete to dopad bude mit jakej? Porad jsou tam ty samy disky, ty samy kabely, ty samy radice a ty samy desky s procesorama. K cemu umele vrstvit timhle zpusobem a zapouzdrovat funkcionalitu jednotlivejch vrstev, aby na sebe nevidely tak dobre?
Ono ZFS ten layered koncept trochu kopiruje, daly by se tam ty vrstvy taky najit, ale mnohem lip si navzajem rozumi.
Uz jenom napriklad RAID5 write hole je s RAID-Z na ZFS absolutni minulosti, nema k nemu jak dojit. Atd. atd. atd. Slepenec neni potreba a vyhodu ma IMHO jedinou, jako vsechny legacy technologie - uz s nim umis, protoze jsi se s nim proste musel naucit, protoze nic lepsiho nebylo.
-
ebik (neregistrovaný)
No, lecktere veci by ale bylo hezke "backportovat" zpet do lvm a raid. At to mohou vyuzit i jini. Napriklad proti te write hole se da bojovat zpusobem, ze filesystem bude (zjednodusene receno) pracovat po celych stripech raidu, a proste nedovoli zapsat do zurnalu ze stripe je v poradku, dokud nevi jestli byl cely zapsan. Nastaveni velikosti stripu mela tusim uz ext2 (i kdyz jen kvuli vykonu).
Slepenec ma jeste druhou vyhodu. Praci odvedenou na raidu a na lvm muze vyuzit kterykoli dalsi filesystem, a nemusi si to implementovat sam. Spravce (jako nevyvojar) pak muze jednotlive casti vymenit a nechat ty okolo. Hlavni problem slepence je ten, ze pro nektere nove funkce by se muselo menit (rozsirovat) rozhrani/protokol kterym mezi sebou jednotlive vrstvy mluvi. A to je zdlouhavy proces, pri kterem je potreba promyslet i pozadavky, ktere by mohly vzniknout, aby se to nemuselo menit casto. Vnitrni protokoly v monolitu se mneni snadno.
-
kdave (neregistrovaný)
S odstavcem 2 souhlasim. Pokud zije pohromade nekolik filesystemu, tak by obecne veci mely byt oddelene a k dispozici vsem. Vylepseni subsystemu pak muze pozitivne ovlivnit i ostatni, viz nedavna prace xfs vyvojaru na per-superblock shinkerech, ktere v dusledku zrychlily writeback u ostatnich filesystemu.
Ten zdlouhavy proces designovani API muze dost podstatne zbrzdit vyvoj, nevim jestli tohle nebyl jeden z duvodu proc to u btrfs proslo. Krome toho, interni raid management je jeho jedina layering violation. ZFS si tak trochu zije ve svem svete (vlastni pagecache, io scheduler, raid, block cache, block devicy) a nema pro nej smysl se ohlizet na nejake zobecnovani vlastnich subsystemu a davat je k dispozici ostatnim. Pro nej to znamena vice moznosti zmen bez nutnosti resit "vztahy se sousedy" a tunit veci ryze podle vlastnich potreb.
Ciste spekulativne, kdyby nahodou ZFS nekdo prelicencoval pro linux-compatible licenci, zacleneni do jadra by znamenalo peclive prekopat vsechny ty subsystemy, co si ZFS z historickych duvodu tahne s sebou a integrovat s temi linuxovymi. Je asi zrejme, ze by to provazelo mnoho diskusi s nejistym vysledkem, co se tyce zacleneni.
-
Dva praktické rozdíly:
Se ZFS můžu mít spoustu různých filesystémů (s různě nastavenými parametry - NFS export, RO, komprimace, ...) a přitom všechny sdílejí stejný prostor - mají k dispozici všechno místo v poolu. To je s jakýmkoli vrstvovým systémem těžko dosažitelný.
Resilvering - úložná vrstva ví, kde jsou data a kde jenom šum, takže mirroruje jenom skutečná data. Při větších kapacitách disků k nezaplacení.
ČLÁNKY DO MAILU