Reiser4: Mrtvý souborový systém?

Úvod

Ačkoli se Reiser4 nedostal, a také asi nikdy nedostane, do jádra, pořád se dají najít uživatelé, kteří tento souborový systém s oblibou používají a nedají na něj dopustit. Reiser4 přináší některé revoluční vlastnosti, které se hojně využívají na serverech, kde je potřeba pracovat s velkým množstvím malých souborů (e-mailové servery, webové cache). Bohužel pro tento souborový systém, Hans Reiser byl obviněn z vraždy, ke které se nakonec i přiznal. Tím padají jeho aktivity kolem Reiser4. Na začátku procesu Hans prodával svoji společnost, která financovala vývoj Reiser4, ale nikdo ji nekoupil, a tak se Namesys nakonec rozpadl.

Případ Hans Reiser: tělo objeveno

Ostře sledovaný případ Hanse Reisera a jeho ženy Niny dospěl k závěru: Reiser se přiznal k vraždě a odvedl policisty k tělu. Pokud vás zajímají detaily tohoto případu, čtěte:

• Hans Reiser hodlá ukázat tělo své ženy
• Hrozí souborovému systému ReiserFS zánik?

• Hans Reiser obviněn z vraždy manželky
• Budoucnost vývoje ReiserFS
• Hans Reiser odsouzen za vraždu prvního stupně
• Budoucnost ReiserFS
• Hans Reiser dovedl policisty k tělu vlastní ženy

Temná budoucnost

Již před Reiserovým obviněním měl Reiser4 problémy dostat se do jádra. Největší překážkou byl styl, jakým byl Reiser4 napsán. Používá totiž staré funkce, další funkce implementuje, i když jsou k dispozici v jádře a v neposlední řadě za to může i chování Hanse Reisera. Když se Reiser snažil dostat Reiser4 do jádra, vývojáři mu začali psát, co všechno musí předělat, aby tento souborový systém přijali. Diskuse se zvrtla do přestřelky mezi vývojáři a Hansem Reiserem.

Hans Reiser v pátek 16. září 2005 zaslal do konference e-mail, kde žádá o zařazení Reiser4 do jádra. Zdůrazňuje přitom, že dosud nebyl nalezen žádný bug v aktuálním kódu. Na to mu pošle Christoph Hellwig výčet nedostatků, které by měly být odstraněny, než se Reiser4 dostane do jádra. K nedostatkům navíc přidává, že kód není čistý, je velmi odlišný od zaběhlého stylu kódu jádra a obsahuje spousty bezcílných věcí. Díky tomuto se kód špatně čte a tím pádem i spravuje ostatními vývojáři. V tomto bodě se technická část debaty zastavila a dále se pokračuje jen vzájemným obhajováním vlastního kódu.

Reiser4 ztratil na několik let svého hlavního vývojáře, a i přes to, že ve vývoji pokračují bývalí zaměstnanci Namesys, kód není vyvíjen jako dříve a potřeboval by oporu od nějaké velké firmy. Že by se dostal do jádra to také nevypadá, a podle mnohých hlasů je Reiser4 mrtvý souborový systém. Potvrzuje to i naše anketa o budoucnosti Reiser4.

Vlastnosti

Reiser4 je velmi vynalézavý souborový systém. Dokonce některé jeho papírové vlastnosti stále nejsou implementované (uživatelské transakce), protože pro ně neexistuje podpora ve VFS (Virtual file system). To je API, které překrývá rozdíly souborových systémů. Díky němu můžou aplikace pracovat se soubory stejně na jakémkoli souborovém systému, podporovaném Linuxem.

B-tree

Pro ukládání inodů používá Reiser4 takzvaný b-tree. Je to variace stromu b-tree. Toto uspořádání dat je velmi rychlé při vyhledávání potřebného inodu. Strom se skládá z uzlů, které obsahují ukazatele na další uzly a také samotné inody. Ukazatele na další uzly jsou seřazeny podle určitého klíče. Při vyhledávání se přečte hlavní uzel s těmito klíči. Každý klíč pak ukazuje na uzel, kde jsou klíče menší než ty ve vyšším uzlu. Takhle se dá velmi jednoduše najít požadovaný inod. Každý uzel může mít pouze N inodů a pokud se toto množství překročí, uzel se rozpadne na dva. Díky tomuto mechanismu má Reiser4 dynamickou alokaci inodů.

Tailpacking

Souborový systém má určitý základní blok dat, se kterým pracuje. V případě Reiser4 se jedná o 4kB velké bloky. Při normální práci se soubory se stává, že soubor není násobkem 4kB. Když vytvoříme soubor o velikosti 6kB, zabere dva bloky a druhý bude z půlky prázdný. V případě konkurenčního souborového systému ext3/4 zůstane tento „ocásek“ nevyužit. Ovšem Reiser4 do něj umí uložit jiný malý soubor nebo „ocásek“ z dalšího většího souboru. To zefektivňuje využití místa například u e-mailových serverů či diskových oddílů, které slouží jako webová cache.

Potulné žurnály

Díky tomu, že Reiser4 nedrží zpětnou kompatibilitu jako konkurenční ext3, může použít modernější způsob žurnálování, tzv. potulné žurnály. Běžný žurnál funguje tak, že nejdříve se veškeré atomické operace zapíší do žurnálovacího souboru. Pokud jsou kompletní, označí se a data se začnou přesouvat na správné místo. Pokud před dokončením všech atomických operací na souborovém systému dojde k nějakému problému, jako třeba výpadek proudu, tak se prováděné operace zahodí. Pokud dojde k výpadku po označení operací v žurnálu za kompletní, je možné celou akci obnovit a celá akce se dokončí.

Reiser4 přišel s novým způsobem práce se žurnálem. Data, která se budou měnit, se překopírují na jiné místo a na původním místě se začne provádět požadovaná operace. Změní se i ukazatele na „postižené“ bloky. Pokud se celá akce povede, označí se, ukazatele se přepíší zpět a soubor bude mít nový obsah. Pokud nastane chyba, tak souboru zůstane obsah původní. Bohužel s touto technikou přicházejí i nevýhody v podobě pomalejšího čtení a větší fragmentace souborů.

Potulné žurnály jsou velmi unikátní a dávají prostor pro další vlastnosti, které ale nemohou být implementovány do souborového systému určeného pro linuxové jádro z důvodu, který jsem zmínil na začátku. Hlavně se jedná se o transakce, díky kterým by mohlo být možné jakékoli zápisy do souborového systému zase vrátit. Tím by se zavedla vlastnost, po které uživatelé volají dlouho, a tou je obnovování smazaných nebo i jen upravených souborů.

Podpora pluginů

Jednou z novinek, která se u souborových systémů nevidí je možnost vytvoření pluginů. Reiser4 je modulární a díky tomu získal jíž dva pluginy, které přidávají podporu komprese a šifrování souborů. Tuto vlastnost nevítají vývojáři jádra, kterým se zdá, že je implementovaná na špatné vrstvě a neměla by být v žádném případě součást Reiser4.

Delayed allocation

Stejně jako souborový systém ext4, tak i Reiser4 obsahuje vlastnost zvanou delayed allocation (pozdní alokace). Pokud vytváříme soubor postupně (například nahrávání streamované hudby nebo videa), tak není předem známé, jak bude soubor veliký. Pokud by souborový systém ukládal na disk soubory hned, jak by dostal nějaká data, vznikala by velká fragmentace. Souborový systém tedy čeká na větší množství dat, co nejdéle je to možné, a až pak zapíše data na disk. Může tak vybrat nejvhodnější a nebude docházet ke fragmentaci.

Porovnání s ext3

S každým článkem o souborových systémech se snažím vylepšit testovací metodiku. Ani v tomto případě to nebude jiné a k testům z minula přidávám testování rychlosti portage. V minulém článku jsem zmínil přechod mého systémového oddílu na ext4. Jako první krok jsem si vytvořil oddíl s ext4 pro portage a práce s ním se několikrát zrychlila. Proto jsem se rozhodl zařadit práci s portage i do testů.

Portage je adresářová struktura, mimo jiné, s tzv. ebuildy, které by se dali popsat jako malé scripty s popisem kompilace a instalace programů (několik kB veliké soubory). Celý adresář obsahuje desetitisíce souborů a podadresářů. Se všemi se pracuje pokud se uživatel Gentoo rozhodne něco najít nebo nainstalovat z dostupných ebuildů. Je to tedy příklad z praxe a ukáže jak na tom daný souborový systém je. Adresář portage, který použiji pro test, obsahuje 108 364 různých malých souborů a 20 346 adresářů.

Pro testování práce s velkými soubory, jsem se rozhodl stáhnout největší verze filmů Big Buck Bunny a Elephants Dreams.

Kopírování portage stromu

Přesunutí portage stromu

Smazání portage stromu

Ve všech portage testech se ukázal Reiser4 jako výhodnější volba. Zde se promítá práce právě s „ocásky“.

Vytváření malých souborů

Reiser4 při vytváření malých souborů zapisuje méně bloků, a i když se drží v kernelu stejně jako ext3, v celkovém čase vyhrává.

Přesunutí malých souborů

Přesunutí souborů je otázkou změny ukazatele, takže tady jsou na tom oba souborové systémy stejně.

Komprese malých souborů

V tomto testu zvládne Reiser4 rychleji dodat soubory tam, kde jsou potřeba. Proto tento test vyhrává.

Dekomprese malých souborů

Dekomprese by měla být časově podobná jako první test, ale ext3 se drží zpátky.

Smazání malých souborů

Mazání malých souborů zdržuje práce Reiser4 s „ocásky“. Je tedy druhý.

Kopírování Big Buck Bunny (692 MiB)

Smazání Big Buck Bunny (692 MiB)

Kopírování Elephants Dream (815 MiB)

Smazání Elephants Dream (815 MiB)

Ext3 se ukázalo jako rychlejší pro práci s velkými soubory, i když je Reiser4 schopný soubor rychleji smazat. Hodí se tedy více na úložiště velkých souborů, například filmů, mp3, atd.

Všechny provedené testy nemusí nutně souhlasit se skutečným výkonem konkrétního souborového systému, protože existuje mnoho faktorů, které by mohly výsledky ovlivnit.

Závěr

Reiser4 je opravdu zajímavý souborový systém a je škoda, že nebyl od začátku vyvíjen s ohledem na vývojáře jádra. Obsahuje vlastnosti, které se v jiných souborových systémech nenajdou a má nakročeno na mnohem větší příčky. Bohužel stav Hanse Reisera tento souborový systém pohřbí. Je tu ale pořád naděje, že se najde firma nebo nějaká organizace, která by se o jeho vývoj postarala.