Reiser4 často rychlejší než Ext4, Btrfs (diskuse)

[xm]

Slušelo by se ovšem podotknout, že řadu testů (které se obvykle v rámci Phoronix Test Suite provádí) nešlo provést, protože na Reiser4 nefungovaly. Jestli to je neschopností Reiser4 nebo Phoronixu však netuším, důvody tam uvedené nějak nejsou.

[xm]

There are many more file-system / disk tests that we normally run in such articles, but these other tests were unable to successfully run on the Reiser4 file-system without crashing.

Takže na vině bude asi opravdu Reiser4.

[cronin]

Takze tym padom cely vysledok, podla ktoreho si "prekvapivo dobre viedol Reiser4", stoji na hlinenych nohach.

[Mythical playboy]

Ext je slepá vetva, keď som sa zonámil s Linuxom, mal som ext3, problémy s vyťažením systému ma priviedli na testovanie FS a jednoznačne vyhral ReiserFS, pred pol rokom som vyskúšal vychvalovanú ext4 a stojí rovnako za ..., kto máte na desktope občasné problémy so spomalením systému, nevysvetlitelným zastavením, alebo kto pracujete s fotkami, kde v jednom adresáry ich máte 500 a viac, prejdite na ReiserFS a budete mi ďakovať Reiser4 som neskúšal, podpora ešte nieje začlenená priamo v jadre a nie som tester aby som si rozbil svoju prácu. Takže ako každý deň sa dozviem čo je zlo, tak pridávam aj ja jedno "ext" je ZLO!!!!

[qwa]

Ještě je hlavní vývojář ReiserFS ve vězení?

[multi]

a uz mu dali do cely pocitac?

[Mythical playboy]

Dostal 25 rokov na tvrdo, takže jedine čo by ho dostalo z väzenia je NASA, alebo CIA, škoda génia, ten by to dotiahol fakt ďaleko.

[Patrik Uhrak]

Dostal 25 rokov na tvrdo, takže jedine čo by ho dostalo z väzenia je NASA, alebo CIA, škoda génia, ten by to dotiahol fakt ďaleko.

A co este jeho zeny...

[Mystify playboy]

Až si niekedy žil s ženskou, vedel by si o tom že od zabitia to žiadna nemá daleko

[Fantomas]

Neni to sice tak hrozne, ale obcas mi ext3 dela zbytecne problemy. Coz se o reiser3.6 rici neda, ten funguje opravdu spolehlive. Skoda autora

[trekker.dk]

Coz se o reiser3.6 rici neda, ten funguje opravdu spolehlive.

To teda rozhodně ne vždycky...

[alblaho]

Na kupu malých souboru je ReiserFS fakt dobrý a ext3 docela nevhodné.

Nicméně ext4 už je na tom o poznání lépe. Navíc je to nejvíc podporovaný a opečovávaný FS. Umí se za běhu zmenšovat i zvětšovat (fajn pro LVM) ReiserFS je naproti tomu v "deep maintenance" módu.

Takže: leta používám ReiserFS k velké spokojenosti, ale nové instalace dělám s ext4.

[Martin Mareš]

Na kupu malých souboru je ReiserFS fakt dobrý a ext3 docela nevhodné.

To hodně záleží na tom, co s těmi soubory chcete dělat. Často to vyjde tak, že ReiserFS sice hezky šetří prostorem, ale operace jsou pomalejší. Také se často liší chování v syntetických benchmarcích a v reálném provozu.

Svého času jsem docela důkladně měřil výkon filesystemů, když jsem vymýšlel, jak by měl Sherlock ukládat na disk stovky milionů malých objektů, a Reiser3 v tomto testu prohrál kalhoty.

[alblaho]

No, reálně to bylo tak, že přechodem s ext3 na ReiserFS se můj desktop subjektivně viditelně zrychlil.

Ale jednalo se o výchozí nastavení v Debianu Sarge, třeba kdybych pro ext3 použil nějaké ďábelské opšny..

To šetření místem (tail-packing) bývá defaultně vypnuté, protože to asi dost zpomaluje. Pro běžné použití na dnešních discích to určitě není vhodné.

Na stovky milionů malých objektů by má inženýrská intuice favorizovala nějakou databázi. Jak to dopadlo u Sherlocka?

[Semo]

To moj desktop kedysi davno tiez prechodom zrychlil, ale to skoro kazdy prechod spravi, pretoze skopirovanim defragmentujes data. Casom som zitil, ze kopirovanie z disku na ten isty disk dosahovalo podobnych rychlosti ako predtym ext3. Ale s ext3 som pri panicu asi 2x stratil data, co sa mi s reiserFS nikdy nestalo. A ked som kvoli debilnej klavesnici zmazal /home na serveri s asi 15 uzivatelmi a vdaka reiseru som asi 99% dat obnovil naspat (a to 1% by slo tiez, len to nemalo vyznam - cache a podobny odpad), tak som presvedceny reiserak.

Na male subory (portage v loop-backu) je samozrejme reiserFS extra vyhodny. Pri velkych je to rychlostne skoro jedno.

[Pavel Francírek]

Degradovat databázi na storage??? To bych vážně neradil.

[alblaho]

Nechci se pouštět do debat, co je storage a co DB. Filesystém je vlastně taky databáze.

Konkrétně jsem měl na mysli něco jako BerkleyDB, SQLite, nebo nějakou tu knihovnu, co používá Beagle. Rozhodně jsem nemyslel na Oracle

[Martin Mareš]

Na stovky milionů malých objektů by má inženýrská intuice favorizovala nějakou databázi. Jak to dopadlo u Sherlocka?

Na Sherločí poměry jsou databáze také příliš pomalé. Dopadlo to tak, že se všechny objekty appendují do jednoho velikánského souboru a ten se čas od času setřepe. Je to v podstatě jediný způsob, jak zařídit, aby šlo rychle procházet všechny objekty (což Sherlock dost často potřebuje).

[hajoucha]

...hmm, a vyhrál jaký fs?

[kralyk z abclinuxu]

ext3 zlo rozhodně není, ale je už prostě zastaralý.

Reiserfs je možná rychlý, ale např. nástroj reiserfsck (u reiserfs 3) je něco naprosto příšernýho. Je nestabilní a ovládání je hrozné. Měl jsem tu čest tento nástroj testovat na různých situacích (ještě o tom dám vědět) a zkušenosti skutečně nejsou pozitivní. Ten nástroj si klidně segfaultuje uprostřed fsck.

Jestli s tímhle ve verzi 4 něco výrazného neudělaj, tak sebelepší rychlost tento FS nezachrání.

Osobně fandím filesystémům jako XFS (velmi robustní, spolehlivý), taky JFS ujde, a slibuju si dost od vývoje Btrfs - ten pravděpodobně dosáhne podobné či možná i lepší rychlosti jako ReiserFS4, ale při lepší stabilitě a spolehlivosti.

[Käyttäjä 11133]

No to je otázka co udělá Oracle jakožto hlavní vývojář BTRFS s BRTFS, když má teďka Sun i se ZFS Kdyby uvolnili ZFS pod GPL bylo by to asi lepší, než vyvýjet BTRFS - ZFS už má například i dedupe.

[thingie]

Vyvýjet btrfs by bylo skutečně nešťastné. Ale vyvíjet ho dál by mohli.

[xm]

Btrfs je pro Linux mnohem vhodnější (taky aby nebyl, když je od začátku vyvíjen pro Linux). ZFS se architekturou do Linuxu nehodí (všechno si řeší po svém, kdežto Btrfs využívá vrstvy které už jsou v kernelu). V něčem je Btrfs i obecně lepší než ZFS. Doporučuji přečíst si článek Krátká historie Btrfs (originál je od Valerie Aurora, dříve Henson - ta holka opravdu ví o čem mluví ).

Jinak pokud vím někde padlo (možná to bylo na mailing-listu?) snad oficiální prohlášení, že Oracle hodlá ve vývoji Btrfs pokračovat.

[Aleš Kapica]

Po testech jsem přemigroval všechny disky z reiser4 na btrfs.

[xm]

Já o migraci taky uvažuji (z JFS, Btrfs zatím jen testuji), ale ještě si radši chvíli počkám, Btrfs ještě stále není označeno za stabilní. Proto se radši pro všechny případy (i když v mých testech jsem na žádný problém či ztrátu dat nenarazil) zeptám - máte ta data zazálohovaná?

[Aleš Kapica]

Jo. Mám zrcadla (ne raidy). Ještě mám v plánu nějaké testy, protože mám podezření na jeden nepříjemný bug. Data sice nezmizely, ale mohly by díky němu zmizet.

Nechci zatím vyvolávat poplašnou zprávu, protože nemohu na 100% tvrdit že je to problém btrfs, ale zkusím popsat:

Mám podezření, že určitých okolností se "ztratí" obsah adresáře. Nepomůže ani sync ani remount. Teprve po fyzickém odpojení, resp. vypnutí a zapnutí disku, se data opět objeví.

Háček je v tom, že pokud během doby kdy jsou data "neviditelná" uděláte rsync s parametrem -d tak vám smaže dat na zrcadle a tam už se pak pochopitelně po remountu nezobrazí nic, protože jsou data smazaná.

Plyne z toho následující. Ano. Data mám na btrfs z následujících důvodů: rychlejší mount, rychlejší checkování disku ale hlavně prespektiva že se tyto bugy i třebas mým přičiněním rychleji vychytají.

Pokud bych setrval na reiser4, tak by se mi mohlo záhy stát, že ty disky budu moct připojit jen pod patchnutou verzí jádra.

Využil jsem tedy toho, že jsem teď koupil dva nové velké disky. Původní s reiser4 byl zaplněný na 99% což už fakt dál nešlo. A přemigroval tak že jsou data rozdělena napůl. Původní disk po přesunu a odzálohování teď funguje jako zrcadlo pro jeden disk z hlavního páru.

[Aleš Kapica]

I ten původní přeplácaný disk byl zrcadlený 1xreiser4 + 1xreiser4 Takže teď mám 2xbtrfs (nové) + 2xbtrfs (původně disky s reiser4).

[Aleš Kapica]

Vzhledem k tomu, že v už na kernel.org sedí v nextu bro btrfs nějaké opravičky, tipuji že jedna z nich bude zahrnovat i tento patch. Soudím tak dle toho, že žádný jiný patch - ať už pro řadu 2.6.32 či nově 2.6.33 v sobě opravu pro btrfs nemá.

[Kvakor]

Mám podezření, že určitých okolností se "ztratí" obsah adresáře. Nepomůže ani sync ani remount. Teprve po fyzickém odpojení, resp. vypnutí a zapnutí disku, se data opět objeví.

Co se stane, když se vysypou všechny buffery a cache zapsáním 3 do /proc/sys/vm/drop_caches? Tím by se zjistilo, jestli data na disku opravdu jsou nebo nejsou.

[multi]

taky mam dobre zkusensti s JFS, hlavne ty subjektivni pri bezne praci na desktopu

[Vykook]

Reiser4 je bloody fast, to mu nelze uprit

[Tomáš Bžatek]

Pouzivam Reiser4 uz od roku 2004 a spokojenost, je to brutalne rychly filesystem. Problemy jsou opravdu jen v nedostatecne podpore od vyvojaru, s kazdou verzi kernelu se chova jinak. Jedu ted par tydnu na nejake 2.6.33-pre6 s opravenym Reiser4 patchem a zatim bez nejmensiho problemu, bez zadneho zbytecne zamceneho souboru. Zatim jsem nikdy neztratil zadne data, i pri problemech s corrupted tree vzdycky pomuze fsck.reiser4 (a potazmo utek k jinemu kernelu, ktery funguje).

[Damian]

Neviete niekto ako sa dari Hansovi? Ma pristup k PC ci internetu? Pise listy? Daju sa mo poslat listy?

[Jan Kundrát (jkt)]

V ceskem jazyce je, pokud vim, forma "rychlejsi nez A, B" ve vyznamu "rychlejsi nez A a B" nepripustna; pokud je pripustna, je zcela jiste stylisticky nevhodna.

[Andrej]

Jedním z možných (a velmi pravděpodobných) vysvětlení, proč některé testy neběžely, je prostě fakt, že žádný Reiser4 patch pro kernel 2.6.33 neexistuje. (Mluvím o situaci k tomuto datu, tedy 3. 3. 2010.)

Zen kernel je ruská ruleta pro otrlé. Autoři tohoto projektu klidně vydali neoficiální a nebezpečný patch pro kernel 2.6.32. Tím přímo ohrozili data spousty důvěřivých uživatelů v době, kdy ještě žádný oficiální patch (od Edwarda Shishkina) pro 2.6.32 neexistoval. Málokoho by v tu chvíli napadlo, že v tom je nějaká levárna a že vlastně používá kód pochybného původu.

Nechápu, proč někdo používá Zen patchset pro benchmark Reiser4, navíc ještě s nepodporovanou verzí kernelu. Může tohle dopadnout jinak, než že to bude nestabilní? Mám dojem, že Phoronix i Zen patchset dělají jinak skvělému souborovému systému medvědí službu tím, že ho šíří a testují v nepoužitelné zmrzačené podobě.

Testování souborového systému pouze na SSD je tak trochu sci-fi nápad, který se většiny uživatelů zatím příliš netýká. (Až bude SSD tak spolehlivé jako klasický disk a až nebude stát desetinásobek, určitě bude všechno jinak. Ale dnes to nebude.) Testy na klasických discích by rozhodně nebyly k zahození. Mě Reiser4 příjemně překvapil nejen na pevném disku, ale i na DVD-RAM. Ve srovnání s často používaným UDF má nesrovnatelně rychlejší mount/unmount a i zápis je mnohem rychlejší, zejména při přepisování souborů.

[Aleš Kapica]

Ve srovnání s často používaným UDF má nesrovnatelně rychlejší mount/unmount a i zápis je mnohem rychlejší, zejména při přepisování souborů.

Platí možná tak cca do 80% zaplnění disku. Pak výkon reiser4 rapidně padá.

[Andrej]

Pokud pouze přidávám soubory, není absolužně žádný důvod, aby při víc než 80% zaplnění významně klesal výkon. (A opravdu neklesá.)

Pokud mám například 90% zaplnění a intenzivně čtu, mažu, přidávám a přepisuji spousty souborů na různých místech, znamená to, že dělám něco, na co příslušná technologie není navržená. Řekl bych, že v takové situaci UDF padá ještě rapidněji než Reiser4. Neznám souborový systém, který by se s tímhle porval zcela bez problémů. Bavíme se tady o seek time řádově 100 milisekund a víc.

Možná, že NILFS2 by takovou situaci zvládl lépe než Reiser4, ale ještě jsem to nezkoušel. Ani to příliš zkoušet nehodlám, protože opotřebení média i mechaniky postupuje v takových situacích příliš rychlým tempem. Takové experimenty už pak se zálohováním nemají v podstatě nic společného.

UDF nemá ani wear leveling, ani log structured zápis. Paradoxně je tedy pro přepisovatelná média naprosto nevhodný, i když lidové pověry tvrdí opak. V porovnání s Reiser4 nemá žádnou výhodu, nemluvě o NILFS2, který implementuje obě zmíněné důležité vlastnosti.

[Tomáš Bžatek]

Viz. muj prispevek vyse. Zen patchset pouzivam od jeho vzniku (merge jinych patchsetu) a nemuzu si jej vynachvalit. Samozrejme je treba mit na pameti, ze je to experimentalni patchset a ne vsechny veci zkratka vzdy funguji. Tyka se to i Reiser4 nebo treba rozbiteho tuxonice. Ale neda se uprit inovativnost, ja osobne jsem rad, ze mi davaji k dispozici na testovani nove technologie, napr. BFS, ktere nekdy zpusobi kolaps a kaskadove deadlocky vetsiny procesu.

Osocovat autory Zen patchsetu, ze dali lidem do ruk nebezpecnou hracku, je zcestne. Je to problem jejich uzivatelu. Nicmene chapu, ze to byla spis narazka na Phoronix, ze si vybrali zrovna tento patchset a vztahuji k nemu chyby filsystemu.

[Andrej]

Narážka se týkala jak Phoronixu, tak i Zen patchsetu.

Pokud by autoři Zen patchsetu prostě vzali Reiser4 a další patche v jejich oficiální (dá-li se to tak nazvat) podobě a přidali je do svého patchsetu, je to naprosto v pořádku. Každý uživatel ví, že jsou to experimentální patche. Většina lidí některé z nich zná a má jasno v tom, co se dá očekávat.

Záležitost, která se stala u 2.6.32, rozhodně korektní nebyla. Zen kernel měl Reiser4 patch víc než o měsíc dříve, než Edward Shishkin vydal svůj oficiální patch. Že je Reiser4 v Zen kernelu poškozený a amatérsky přiohnutý, jen aby se s kernelem 2.6.32 zkompiloval, bez ohledu na funkčnost, to se vědělo prakticky ihned po vydání příslušného Zen patchsetu. A co udělal projekt Zen? Nic. Autoři se ani neobtěžovali napsat na své stránky varování ohledně Reiser4, aby uživatelé s upgradem počkali a zůstali u 2.6.31, dokud nebude oficiální patch k dispozici.

Samozřejmě, že autor free software nemá v tomto směru absolutně žádné povinnosti. Ale nějaká ta základní slušnost by neuškodila.

[Tomáš Bžatek]

Autori samozrejme napsali, ze je nefunkcni, ale ne hned u prvniho releasu. Ja to taky teda zjistil az pozdeji, problem se tykal jen syncu, pri malych zapisech a read only pristupu modul nepadal a fungoval mi. Podle tveho tvrzeni by bylo lepsi, aby patch nebyl zpocatku vubec zarazen a uzivatele se ke svym datum nedostali...

[Andrej]

Ano. Rozhodně a jednoznačně. Vystavit uživatele riziku ztráty dat, které se dalo snadno předvídat, je neomluvitelné. Odložit upgrade kernelu o měsíc je proti tomu zcela nepodstatný problém.

Nepochybuji o tom, že read-only přístup fungoval. V takovém případě tam mělo být od začátku velké tučné varování, případně hack, který R/W přístup zakáže.

Jeff Bonwick, vývojář Solarisu a gatekeeper verze 2.5, kdysi poznamenal velmi trefně „mistakes will happen; negligence cannot“.

Distribuce amatérsky poškozené verze souborového systému není mistake, ale negligence.

Nebýt těch benchmarků na Phoronixu, nikdy bych o tomhle nepsal. Je to minulost, stalo se. Věřím, že se z toho všechny zúčastněné strany poučily. Tlustá čára, hotovo... Jenže pak přijde Phoronix, vezme Reiser4 z téhož pochybného zdroje, provede jakýsi benchmark a diví se, že (jaké to překvapení!) některé části benchmarku nefungují. To mi připadá jako dost nekorektní přístup k věci, který dělá špičkovému souborovému systému medvědí službu. Vytváří totiž FUD.

V okamžiku, kdy má někdo pochybnosti o spolehlivosti souborového systému, je mu zoufale jedno, jestli je o 10% rychlejší nebo dvojnásobně rychlejší. Prostě ho nepoužije. Tím začíná Quality Death Spiral, o které píše Jeff Bonwick. Bylo by smutné, kdyby v té spirále skončil Reiser4.

[Tomáš Bžatek]

Ano, nazor na Phoronix beru, je rozumny, na jadro uz ne, ale k tomu jsem se uz vyjadril. Zkratka je na uzivateli, jestli pokazenou vec pouzije nebo ne. Kdyby meli tvuj pristup aplikovat na ostatni komponenty patchsetu, asi by jej nemuseli vubec vydavat. Tuxonice taky nefunguje, BFS zpusobuje tuhnuti systemu, LIRC mi vcera hodil oops, BFQ a genetic library take ne... a varovani nikde. Nepovazuju to za pruser a neocekavam, ze by si z toho meli autori patchsetu brat ponauceni, je to proti jejich filozofii vydavat bleeding-edge veci.

[xm]

BFS používám už dlouho (někdy od září nebo října 2009, byl to tuším kernel 2.6.31 a revize BFS tuším 240 nebo tak nějak) dohromady na 3 strojích a _nikdy_ jsem se se žádným zásekem či tuhnutím nesetkal. Vím, že tam nějaké problémy jednu dobu být měly, ale ty jsou už dávno opraveny. Ovšem používám samostatné BFS, žádný kombinovaný zen patchset.

[Andrej]

Možná to bude jen další z amatérských zásahů ze strany autorů Zen patchsetu.

[Tomáš Bžatek]

Jo i to je mozne, moc jsem se s tim nezabyval, tech zatuhu bylo jen par, v novejsich verzich uz chodi bez problemu. Tehdy jsem nasadil BFS hned po oznameni a prvnim funkcnim bootujicim patchi.

Dalsi pricinou byl asi hardware ci jeji kombinace, tuhla mi pouze pracovni masina pri vetsi zatezi (quad core, nouveau, load 5 a vyssi), domaci masina (dual core, intel) chodila vzdy stabilne.

[Andrej]

Tuxonice i BFS mi fungují. Nepoužívám ovšem žádný Zen patchset. Nejspíš i tyto patche dokázali autoři Zen patchsetu nějak poškodit. Jiné vysvětlení mě nenapadá.

Myslím si, že mezi nefunkčním BFS, kvůli kterému „popuze“ zatuhne systém, a nefunkčním Reiser4, který může (hypoteticky) poslat celý uživatelův oddíl do kytek, je propastný rozdíl.

[Andrej]

s/popuze/pouze/

[Tomáš Bžatek]

Je to uz nejaky patek, co jsem zkousel tuxonice v zenu, tehdy jeste zadne BFS nebylo. Problem byl s uspanim nekterych procesu, velkou merou se na stabilite take podepsala prvni mainstream verze KMS. Osvedcene tuxonice-sources chodi bez problemu (v ramci mezi, kdyz zmizne swap, ktery si to dokaze krasne znicit, uklada buhvi kam a pak zpanikari).

[Luboš Doležel (Doli)]

Já jsem skončil u ext4, protože stejně je ve většině reálných situací největší skutečnou brzdou hardwarová zaostalost harddisků a za ten risk mi ten rychlostní zisk nestojí.

[Mystify playboy]

Ja osobne na takéto testy kašlem, pre mňa je podstatná realita a to sú hlavne nevysvetliteľné spomalenia nevyťaženého systému, nedávno to jadráci rozoberali a zistili to čo ja už viem roky že to spôsobuje ext3 a po mojich skúsenostiach aj ext4, ext môže za väčšinu nevysvetlitelných situácií (nie len to spomalenie) ktoré som riešil vo fórach, po prejdení na ReiserFS všetko ide ako má.

[Martin Mareš]

Inu, ona to nezpůsobuje ani tak ext3, jako spíš prostý fakt, že spousta desktopových aplikací dosti často a dosti zbytečně volá fsync(). (Viz diskuse na LKML před několika měsíci.)

[xm]

Což ovšem je chyba ext3 (ta pomalost při fsyncu), jelikož ext3 má debilní návrh a místo aby syncovala jen dané soubory, syncuje kompletně všechny soubory.

[Martin Mareš]

To je ještě pravda? Nemyslím, že by byla. Nicméně fsync musí počkat, až se dokončí celá započatá transakce v žurnálu, což může trvat poměrně dlouho (neumí předběhnout).

Každopádně je od autorů aplikací pitomost předpokládat, že fsync je rychlá operace, kterou by bylo možné volat často. Na některých FS je pomalá, na jiných ještě pomalejší. Rychlá nikdy.

[trekker.dk]

Což AFAIK dělá většina souborových systémů, protože dělat to jinak je podstatně složitější - viz článek Valerie Aurory tady na abc.

[M. Lox]

Zrovna Reiser4 má per-atom flushing, takže syncuje soubory nezávisle.

[xm]

Btrfs nemá s per-file nebo per-directory fsyncem žádné problémy. Takže bych vás opravil - dělá to tak většina předpotopních souborových systémů

[xm]

Btw. článek Don’t fear the fsync! od Teda Ts'o znáte?

[Heron]

Vynikající, dávám do bookmarků.

[m1c4a1]

Já na poslední laptop nasadil taky ext4, ale to jen proto, že jsem si ho chtěl zkusit. Zažil jsem ext2, ext3, ReiserFS4 a teď i ext4 a jako běžný uživatel prostě rozdíl nepoznávám. To by mi musely běžet vedle sebe 2 stejný počítače provádějící 2 stejný úkoly. Že bych si jako na nějakou partišnu s ext4 nakopíroval tisíce obrázků a pak je zkoušel třeba kopírovat, a pak to samý prováděl na ReiserFS4 partišně, to není běžná uživatelská činnost.

[Jardík]

SPADFS rulez.

[Martin Matějek]

"Spad" is abbreviation for Czech Systém pro Psychopaty A Debily (System for psychopaths and idiots).

Co jiného taky čekat od BLEKa

[Jardík]

Alespoň je to rychlejší než ext*

[Martin Matějek]

Proti tomu žádná, podle návrhu to musí být rychlejší než ext*. Prostě mě to pobavilo.