Používání ZFS přes FUSE

Pokud vás zajímá souborový systém ZFS, podívejte se na Linux.com, kde se probírá jeho provozování přes FUSE. Zároveň je tam předveden rychlý benchmark, ve kterém je dosahováno pouze 30 až 60 % výkonu XFS. FUSE implementace představuje brzdu především při zápisu.

19.6.2008 14:01 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[dayvee]

fuse je genialni vec, ale pouzivat filesystem permanentne mountlej pres fuse bych fakt nechtel ... skoda ze sun vydalo zfs nekompatibilni s gpl, protoze bych ho mel asi hodne rad )

[roman]

jake stesti ze ve FreeBSD mame jak ZFS tak Dtrace ;)

[NaiL]

a aj linux-compatibility-layer :)

[linear]

hlavne kdyz jste vsichni 3 spokojeni

[otula]

Je to sice trochu OT, ale si tak říkám, že když místo Truecryptu 5 (používajícího fuse) používám verzi 4.3a, která přes fuse nejede, tak dělám dobře

[cthulhu]

to rozhodně děláš. po celodenním laborování TC 5.1a versus Hardy jsem TC vykopal pryč a nikdy už mi (na Linux) nesmí. Při kopírování velkého (několik GB) množství dat docházelo k zasekávání zápisů, fs nešel odmontovat a nezbývalo nic jiného než init 6. Ostatně je možné se o tomto chování přesvědčit všude možně viz. google (celá pětková řada). Pokud nejsou požadavky na přenositelnost (v případě FAT32/NTFS uvnitř kontejneru), nezvolil bych už nic jiného, než výkonnější LUKS.

[otula]

Díky za reakci. Verzi 4.3a mohu jen doporučit, problémy jsem s ní neměl nikdy. To, že v pětce nejde odmountovat fs, byl hlavní důvod, proč jsem se urychleně vrátil ke starší verzi - byl to úplně první problém, na který jsem narazil, ale myslel jsem, že asi něco dělám špatně (v tom smyslu, že se to v pětce dělá jinak) a řešit se mi to nechtělo.

[unknown_]

No jo, to ta vaše GPL...

[Rampa Mac Kuak]

Ty hele nezačínej si, nebo ti RMS zakáže používat GPL software na BSD :)

[unknown_]

však už snad brzo bude lcc dostatečné fungující, a pak mě to trápit nebude.

[xm]

Na FUSE bych to opravdu nesváděl, viz rychlost ntfs-3g, která v některých situacích překonává dost znatelně třeba nativní ext3.

[alpha]

Odkazy nejsou? Dle mych soukromych testu je ntfs-3g asi 2× az 5× pomalejsi nez vsechny ostatni – nativni – linuxove FS (ext2, ext3, JFS, XFS, ReiserFS a Reiser4).

[Luk]

Ono to opravdu může být rychlejší. Pokud má někdo ďábelsky rychlý procesor i paměť a současně pomalý disk, může mu to skutečně běhat rychleji, i když je to přes FUSE. Vlastnosti filesystému převáží. Hlavně u velkých souborů má NTFS oproti ext3 dost navrch, hlavně pokud není příliš fragmentovaný.

[Jiri Bajer]

Dost taky zalezi na velikosti dostupne RAM - ZFS schroupne docela dost pameti a pod 2GB RAM se IMHO moc nevyplati... Ma nekdo dobrou zkusenost s pouzivanim ZFS na slabym zeleze (malo RAM)?

[Mandarinka]

Hm, odkdy je RAM v kompu na to, aby umožnila běh FS?

[unknown_]

Od té doby, co je ZFS?

[Vskutečnosti Saýc]

RAM (nebo lepe receno virtualni pamet) se pouziva ke kesovani dat z disku, aby k nim byl rychlejsi pristup. Chytre systemy taky uklada data pri zapisu nejdriv do RAM, a potom je pisi na disk aby nebrzdily aplikace, a tak podobne. Velikost RAM je s vykonem souborovych veci dost spjata.

[Fox]

chytrost onoho chytreho systemu se projeví zejména při dobře načasovaném výpadku alaktřiny... "huh eště že sem to uložil" áále neuložil....

[Filip Jirsák]

Zajistit dodávky elektřiny ovšem není úkol souborového systému, ale úplně jiných komponent. Pokud by to bylo, jak popisujete, byl by nejdokonalejší souborový systém FAT nad nějakým hodně starým diskem, který nemá žádnou interní cache.

[Ondroid]

Obvkle je synchronizace nastavená na pár vteřin, tak výpadek zase takovou katastrofu nudělá.

[Vskutečnosti Saýc]

Zrovna uz ZFS se bavime o nanejvys vterine. Snazi se si ty zapisy prerovnavat, aby bylo co nejmene potreba soupat diskem sem tam. Navic cteci operace maji prednost pred zapisovymi, protoze aplikace zapise data a dal se o ne nestara, kdezto pri cteni na ty data aplikace logicky ceka. Takze zpomalit zapis o pul vteriny vymenou za rychlejsi cteni muze byt dobra vec.

[alpha]

Proc ne? Kdyz bude ten FS dost rychly na to, aby se to vyplatilo…

[Milan Jurik]

Je ASUS Eee dostatecne slabe zelezo?

[Ondroid]

Já jsem hodně zvědavej co se vyklube z konkurenčního Btrfs. Ten je aspoň pod GPL a nepotřebuje Fuse.

[xm]

A je podstatně rychlejší a méně paměťogvě náročný i než nativní ZFS na Solarisu

[Milan Jurik]

Prosil bych o relevantni vysledky mereni. Pominu aktualni stav brtfs, staci ty vysledky mereni. Ja jen, jestli to neni stejne kvalitni mereni jako to porovnavani ntfs-3g vs. ext3 (ne, ze by v nekterych operacich za urcitych podminek nemohlo byt ntfs-3g lepsi)

[cthulhu]

zajímalo by mě, kolik zdejších ZFS "nadšenců" tento souborový systém opravdu používá produkčně a déle než rok a na business critical / business important službách (ještě nedávno Solaris se zónami na ZFS nešel ani zupgradovat!) nebo databázových (Oracle) strojích. Pokud jde o mě, sleduji nekončící příval bugfixů na tento opravdu revoluční FS a zatím rozhodně zůstávám u lety prověřených UFS/VxFS.

[Milan Jurik]

Ja se asi nebudu pocitat, ze? Jednak nejsem ZFS "nadsenec" a jednak ZFS na business critical/business important sluzbach potkavam uz skoro 3 roky, ovsem, pravda, v nestandardnich podminkach.

[Vskutečnosti Saýc]

Jakych? Jsem docela zvedavy.

[cthulhu]

afaik ZFS oficiálně vyšel spolu s 06/06, on někdo provozuje b.critical službu na OpenSolarisu? (nevím kde jinde by se před třemi roky ZFS vzal..), ZFS nepodporoval (nevím jak je na tom aktuálně) odebrání toplevel vdev-u, neumí shrink, pokud jde neredundantní disk v zpoolu do offlajnu, zpanikaří celý systém (fakt chuťovka) a jistě by se našly další "vychytávky". Vůbec mi připadá, že celá řada nových featur Solarisu 10 se až příliš dlouho "usazuje" (Problémy se zdlouhavým patchováním a lokálními zónami, lokální zóny vs. LiveUpgrade, resource capping, schizofrenie SMF vs. legacy..)

[Milan Jurik]

Na cem myslite, ze si ukladame a pracujeme v Sunu? Ale jinak jsou firmy, ktere uzivaji Solaris Express uz roky ve svem business prostredi a verejne to prezentuji.

Jinak to, ze vam "umre" neredundatni disk v zpool a nasleduju panic, je feature, ne bug To se vam stane i v UFS, proste pokud system nema kam splnit pozadavek na zapis, radsi zpanikari nez by "tajne" zahodil data. Otazka filozofie. Samozrejme, ze to lze v dnesni dobe nastavit na alternativni moznost nezpanikareni.

Ovsem pokud mate napad, jak zaridit, aby aplikace se dozvedely, ze zapis na disk neprosel (hint - cache), tak sem s nim.

Btw. clovek, ktery provozuje business critical nasazeni s neredundatnim diskem, to je dost riskantni, neprijde vam?

Jinak vas mohu ubezpecit, ze ZFS se uziva v docela slusne mire v kritickych nasazenich, takovych, ze jejich rozsah u nas tezko najde obdoby.

Jeste, co se tyce shrinku, tak furt vidim vsude komentare, jak je strasne, ze ZFS nepodporuje shrink, ze se bez toho neda zit atd. Pritom CR 4852783 je P4 a neprijde mi, ze by to bylo nejak moc horke z pohledu skutecnych uzivatelu.

[cthulhu]

Jako vtip dobrý, taky jeden zkusím. sunsolve taky zřejmě jede na nějaký beta technologii, protože je pomalej a zabugovanej (navzdory platnému kontraktu nezobrazuje některé dokumenty protože prý nemám kontrakt..) k uzoufání, přechod na nový systém zatím zdá se v nedohlednu. Podle vaší logiky by při plném aplikačním filesystemu měl jít systém do paniky (než by aplikaci "zahodil" data), zřejmě se tak neděje a myslím si, že je to dobře. Dokážu si představit celou řadu případů, kdy ačkoliv služba jako celek představuje důležitost značnou, přesto nepotřebuje mít některé filesystemy redundantní (temporary data, která se dají lehce znovu vygenerovat). Jako zaměstnanec Sunu bych si na notesu jistě honil roota na ZFS s Nevadou, jako zákazník Sunu se (po tom množství crashů, co jsem na desítce viděl) už skoro bojím, co mě zítra v provozu zase potká (zatímco osmičkám a devítkám vesele naskakuje uptime).

[Milan Jurik]

K sunsolve se nevyjadruju, mate platny kontrakt, umlatte Sun support. Co ja vim, tak sunsolve na novy system presel pred casem.

Podle vaší logiky by při plném aplikačním filesystemu měl jít systém do paniky (než by aplikaci "zahodil" data), zřejmě se tak neděje a myslím si, že je to dobře.

E? Ano, mel, protoze by jste asi neocenil, kdyby jste po par hodinach zjistil, ze veskere zapisy, provedene na ten disk, jsou v trapu. Sorry, ale obavam se, ze ani FMA nema plugin "kladivko pro hlavu admina", aby dalo na vedomi, ze je neco opravdu spatne. A to, ze by se to zapsalo nekam do logu, no nic moc. Tohle neni ZFS, to je design Solarisu, radsi okamzite zastavit praci nez nahodne zahazovat data.

Dokážu si představit celou řadu případů, kdy ačkoliv služba jako celek představuje důležitost značnou, přesto nepotřebuje mít některé filesystemy redundantní (temporary data, která se dají lehce znovu vygenerovat).

A proto mate moznost rici, ze dany filesystem za podstatny nepovazujete a system nemusi panikovat. Ano, tato moznost tam nebyla od pocatku, ale v UFS neni vubec.

Jako zaměstnanec Sunu bych si na notesu jistě honil roota na ZFS s Nevadou,

Az na to, ze ja nemluvim od honeni si rootu na ZFS s Nevadou (neprovozuji dosud a za kriticke nasazeni to nepovazuju), ale treba o storage pro sdilene build systemy, vcetne supportu. Takze predstava, ze prijdu o fixy, ci buildy s patchem pro zakaznika a budu cekat, az dopadne obnova z pasek, to bych nebyl rad. A management take ne, musel by to vysvetlovat zakaznikum.

jako zákazník Sunu se (po tom množství crashů, co jsem na desítce viděl) už skoro bojím, co mě zítra v provozu zase potká (zatímco osmičkám a devítkám vesele naskakuje uptime).

To za ty crashe mohlo vzdy odpojeni neredundantniho disku ze zpoolu?

Chapu vasi nastvanost na S10, ale k tomu je Sun support, ne diskuze Linux/FUSE/ZFS vykonnost.

[cthulhu]

Asi se na to holt koukáme jinak. imho zaplnění/nezaplnění FS (a také capacity planning) je věc aplikace a aplikačního supportu, já jakožto admin končím na úrovni mountpointu. Co když na serveru běží aplikací víc (každá má svoje disky), to mají ostatní apps jít "na hubu" i se systémem, jenom protože byla jedna jediná "neukázněná"? Nesouhlasím. Systém se právě snaží aplikace držet nahoře seč může (je to taky jeho primární úloha), přestože swapuje jak o závod a nekde se na něj skoro ani zalogovat. Nechápejte mě špatně, ZFS docela fandím (Sun se zbaví toho věčného veritasího "přívěšku"), jenom jsem vyjádřil svoji skepsi ohledně bleeding edge technologií, offtopic stabilitu S10 tu opravdu řešit nebudeme. Zmínka o ZFS na notebooku opravdu nemusela být, lehce jsem se tím snažil naznačit, že pokud automobilový závodník a zástupce automobilky jezdí s autem po dvou kolech (a závodní okruh má hned vedle servisu), nemusí to být úplně to pravé pro konzervativnějšího strejdu co zrovna veze bábu s dětma.

[Milan Jurik]

Asi se na to holt koukáme jinak. imho zaplnění/nezaplnění FS (a také capacity planning) je věc aplikace a aplikačního supportu, já jakožto admin končím na úrovni mountpointu.

Jenze nedostupnost disku je neco jineho nez zaplneni fs. Dostupnou kapacitu fs overite pri operaci write a poslete aplikaci k sipku, ale kdyz uz te aplikaci slibite, ze ty data zvladnete ulozit a pak vam umre ten disk, kam je mate strcit, proste mate smulu, ta aplikace na tom muze byt zavisla, muze zacit mrvit dalsi data atd. Proste v tuto chvili je asi nejlepsi umrit a nechat na adminovi, at napravi stav na zaklade svych schopnosti

Co když na serveru běží aplikací víc (každá má svoje disky), to mají ostatní apps jít "na hubu" i se systémem, jenom protože byla jedna jediná "neukázněná"? Nesouhlasím. Systém se právě snaží aplikace držet nahoře seč může (je to taky jeho primární úloha), přestože swapuje jak o závod a nekde se na něj skoro ani zalogovat.

Tehle situaci rozumim, jenze jak ma system vedet, ktera aplikace je ta zasadni a ktera ne? Jak ma vedet, zda mezi sebou ty aplikace nezavisi skrze ta data? Ja verim, ze to neni prijemna chvile, kdyz system zcrashuje, ale on v te chvili opravdu panikari.

Nechápejte mě špatně, ZFS docela fandím (Sun se zbaví toho věčného veritasího "přívěšku"), jenom jsem vyjádřil svoji skepsi ohledně bleeding edge technologií, offtopic stabilitu S10 tu opravdu řešit nebudeme. Zmínka o ZFS na notebooku opravdu nemusela být, lehce jsem se tím snažil naznačit, že pokud automobilový závodník a zástupce automobilky jezdí s autem po dvou kolech (a závodní okruh má hned vedle servisu), nemusí to být úplně to pravé pro konzervativnějšího strejdu co zrovna veze bábu s dětma.

To vam neberu, prave proto jsem na zacatku napsal, ze asi nejsem zapocitatelny do vaseho scitani