Ext2, XFS, ReiserFS - který je lepší?

Obvykle je snaha úspěšná, ale toho ztraceného času a okamžiků nejistoty při tisku Yes může být tolik, že vyvstane otázka: „Mám já tohle vůbec zapotřebí?“ Obecně vzato je odpověď poměrně jednoduchá a zřejmě nejsnadnějším řešením je, sáhnout po některém z žurnálovacích souborových systémů. Dříve to znamenalo stáhnout si balíček a nainstalovat si ReiserFS v jeho betaverzi. Operace nikoli složitá, nicméně Reiser nebyl ve stavu stoprocentně odladěném. Mohlo se tak snadno stát, že data a čas, která jste chtěli zachránit, si jako oběť vzal nikoli bůh ext2, ale ReiserFS.

Žurnálovací souborový systém
Většina z vás jistě ví, co to znamená, pokud ano, mohou klidně přeskočit na následující odstavec. V krátkosti se jedná o převzatou standardní a nutnou součást velkých databázových systémů, kde není možné riskovat, že se vyšle požadavek k zápisu dat a ono se to snad udělá.
V žurnálovacím FS se požadavek a jeho popis uloží na bezpečné místo a poté se teprve odešle diskovému susbsystému ke zpracování. Je-li operace úspěšná, poznámka se vymaže a je vše hotovo. Pokud by nastal nějaký problém, je vždy možné pomocí uložených poznámek, jejich časového razítka a příslušné utility dohledat, co se mělo změnit a jak to dopadlo. Při pádu systému, například v důsledku přerušení dodávky proudu, se tedy zkontroluje jen zásobárna poznámek a obnova dat a jejich kontrola tak trvá řádově zlomky času nutného pro kontrolu a obnovu klasickou cestou. Na druhou stranu žurnálování vyžaduje určitou část výkonu procesoru a není příliš skromné ve spotřebě paměti. Je nutné mít na vědomí, že aby měl žurnálovací FS šanci zlepšit výkon stroje, musí mít z čeho tento výkon odebrat. Na 486-ce zlepšení příliš neočekávejte.
O ReiserFS se více dozvíte zde.

Dnes je však na poli souborových systémů (dále jen FS, případně ZFS) situace poněkud jiná a nebojím se říci, že mnohem lepší. ReiserFS vyspěl do stabilní spolehlivé verze a je přibalován jstandardně k jádrům od 2.4 výše, z kódu a know-how firmy SGI (bývalého Silicon Graphic) vznikla linuxová verze XFS a na obzoru se rýsuje příspěvek od IBM a dalších. Téměř se nabízí otázka, zda se stran používání a obliby jednotlivých souborových systémů nepřihodí něco podobného jako mezi jednotlivými distribucemi Linuxu. Skutečně nebude snadné si vybrat a kromě kvality do hry jistě vstoupí i další faktory. Aby vaše volba budoucího souborového sytému byla o něco snazší, dali na Universitat de les Illes Balears hlavy dohromady a vyšel z toho benchmark mezi XFS, ReiserFS a starou dobrou ext2. Původní verze byla ovšem ve španělštině, což většinu anglicky mluvících linuxáků příliš nepotěšilo. Ricardo Galli však věnoval svůj čas dobré věci a tak vznikla tato anglická verze článku. Jelikož jsme v zemích českých, není ani anglická verze pro mnoho z nás nejpřínosnější, a proto se pokusím o velmi stručný výtah přeložený do češtiny. Pokud vás zajímají použité algoritmy, jsou obsažené jako linky v originálním textu a až na zvláštní výjimky je nebudu přepisovat.

Konec povídání, podívejme se na překlad:

Především bych chtěl předeslat, že zde není žádný jasný vítěz. V něčem je lepší XFS, v něčem zase ReiserFS, a oba jsou lepší než Ext2 díky žurnálovacím schopnostem. Výborné je, že linuxové buffer/cache operace jsou velmi výrazně pozitivně ovlivněné a veškeré výsledky kompilování, kopírování, náhodných zápisů a čtení též. Čili mohu říci, kupte si více paměti a jděte do žurnálování ASAP…

Originální verze benchmarků napsal Guillem Cantalops a poskytl též novější verzi. Mongo benchmark je však přímo od Hanse Reisera. Při testech na pomalém stroji (Cyrix MII 233MHz, 128MB SDRAM, Samsung SV0844A hard disk) byl pro malé soubory (100 až 1000B) ReiserFS nejrychlejší, zatímco pro velké soubory byl extrémně pomalý. „Průměrná“ velikost souborů v dnešních distribucích je kolem 16KB. Nebyli jsme přesvědčeni o použitelnosti těchto výsledků právě díky pomalému stroji a proto jsme provedli měření na poněkud rychlejším počítači (Pentium III, 800 Mhz, 512MB SDRAM a Seagate ST330621A hard disk). Ačkoli byly výsledky srovnatelné s předchozími, lze říci, že se mnohem více blížily k výsledkům dalších testů.

Kompilace linuxového jádra
Systémy byly samozřejmě otestovány i kompilací jádra. Test proběhl třikrát a skládal se z cp, make bzImage, make clean and rm -r. Na základě informací Hanse Reisera, že využívání volných částí sektorů pro data jiného souboru (dále označováno jako tail) může snížit výkonnost (což v rámci tzv. Plánu A je zohledněno v jádru 2.4 a Reiser4), jsme otestovali jak s taily, tak s nastavením mount -o notail. Výsledky průměru ze tří testů jsou v tabulce.

Test proběhl na stejném stroji: Pentium III, 800 Mhz, 512MB SDRAM and a Seagate ST330621A. Disk (7GB) byl „vyčištěn“ rm -rf * a odmountován a znovu přimountován. Díky cache byly velké rozdíly v měření prvního cp a proto je bylo nutno vícekrát opakovat.

Test náhodného zápisu, čtení a přesunu

Předchozí testy všech FS ukázaly, že navzdory velmi pomalému kopírování pod XFS jsou si velmi blízké stran wall času a CPU času (wall-clock, CPU times). Mě však zajímala otázka, co se změní při testu „malé databáze při reálné zátěži“. Skutečná databáze totiž provádí spoustu lseeků a čtení a zápisů různě velkých objemů dat a jen sporadicky zapisuje nová data. Někdy následuje fsync hned po zápisu a velikost souborů po přidání dat narůstá jen velmi málo. Proto jsem sestavil pět souborů různých velikostí (1, 10, 100, 250 a 500MB), větší testy by zabraly hodiny.

#! /bin/sh
for i in 1 10 100 250 500
do
        echo $i
        dd if=/dev/zero of=/mnt/$i.dat bs=1M count=$i
        chmod ugo+rw /mnt/$i.dat
done

Poté jsem pomocí malého céčkového programu (je přiložen na konci originálního textu) spustil test, který cykluje (100×) mezi těmi pěti soubory a pro každý cyklus náhodně přistoupí do kazdého z nich (100 x lseek, read buffer 16KB) a pak v 25% případů lseek zpět na předchozí pozici, kde zapíše onen buffer a následuje fsync souboru.

Časy jsem obdržel modifikací předchozího scriptu a spočtením průměru ze tří měření.

Závěrečné zhodnocení

Zaznamenal jsem rozdílné výsledky pro různou velikost zpracovávaných souborů (Mongo benchmark), a tak jsem chtěl zjistit, jaký dopad to bude mít při použití v reálu, kdy Linux VFS a cacheovací techniky mohou ještě dále dramaticky zvýšit výkon systému.

V případě kompilace jádra měla Ext2 velmi malý výkon při kopírování souborů. V jiných testech je ReiserFS s notail nastavením vítězem, ale výsledky Ext2 a XFS byly často velmi blízko, přičemž rozdíl pro make bzImage činí pouhá 2%.

Když jsem testoval promíchané lseek, read, write, fsync na souborech rozdílné velikosti, se ziskem 8% na ReiserFS zvítězil XFS.

Výsledkem analýzy všech výsledků je, že se zdá, že za běžných podmínek mají XFS a ReiserFS vyšší výkonnost než Ext2 a navíc ještě poskytují výhody žurnálování.

Co říci závěrem? Jste-li tzv. domácí uživatel, majitel malého serveru s relativně rychlým CPU, použijte ReiserFS nebo XFS, oba jsou velmi stabilní a rozdíly mezi nimi jsou minimální, téměř neexistující.

---

Já jen dodám, že ReiserFs je dílem Hanse Reisera a podrobnosti si můžete přečíst zde, zatímco XFS je původem od SGI a nějaké informace naleznete například zde