Malý domácí test filesystémů Ext3/Ext4/XFS/JFS/Reiser4/Btrfs

1.9.2010 12:01 | Přečteno: 8073× | linux | | poslední úprava: 1.9.2010 13:00

Už delší dobu jsem zvažoval jak vyřešit doma problémy s nedostatkem místa a nonstop přístupem k audiovizuální knihovně. Od prvních úvah o HTPC jsem se přes out-of-the-box NAS řešení dopracoval až k tomu, že nahradím můj starý a minimálně používaný PC takovým hybridem mezi NASkou, domácím serverem a příležitostným desktopem. Volba z důvodu spotřeby padla na Intel Atom s ION chipsetem. Jako úložná média bude obsahovat dva SATA disky 750GB a 1,5TB. Je jasné, že výkon takového stroje dokáže značně ovlivnit i práce s disky a proto jsem se rozhodl otestovat současné filesystémy, abych vybral pro mé potřeby pokud možno ten nejlepší.

Předem uvádím, že na testu nijak nebazíruji. I díky jiným testům, které jsem na webu našel je mi jasné, že neexistuje univerzálně správný a 100% vypovídající test, takže to berte spíš jako podělení se o zkušenost než cokoliv jiného. Testy samoté probíhaly na PC s Athlon XP 2500+, 2GB RAM, s několika různými disky z nichž jeden Seagate SATA 40GB jsem vyhradil pro testování. Před každou serií testů byl proveden restart PC a formát partition na příslušný FS. Samozřejmě jsem před testy vypnul KDE a jiné potenciální nařušitele klidu a míru, aby CPU mohl veškeré své drahocené zdroje propůjčit probíhajícím testům. Testovalo se na jádře 2.6.35.4 s Reiser4 patchem na Debian 6.0 Squeeze i386. Pro mountování všech systémů byly použity výchozí volby, pouze u Ext3 a Ext4 jsem použil 'data=writeback'. Meření bylo prováděno pomocí GNU Time. Každý test jsem 3x zopakoval, aby byly výsledky alespoň malinko věrohodné.

Test 1 - Rozbalení aktuálního jádra 2.6.35.4 z bz2 archivu, zdroj na jiném disku cíl na testovacím. [tar, bzip2]

Test 2 - Změna pořadí audiostop filmu v mkv (cca 9GB), zdroj na jiném disku cíl na testovacím. [mkvmerge]

Test 3 - Překopírování rozbaleného jádra z kroku 1 do jiného adresáře. [cp]

Test 4 - Smazání původního rozbaleného jádra z kroku 1. [rm]

Test 5 - Smazání vygenerovaného mkv souboru. [rm]

 

Výsledky dopadly takto:

 

		Test1		Test2		Test3		Test4		Test5
		time [m:s]	cpu [%]	time [m:s]	cpu [%]	time [m:s]	cpu [%]	time [m:s]	cpu [%]	time [m:s]	cpu [%]
JFS	Pass1	01:29,50	64	02:54,40	73	01:08,30	6	00:14,03	6	00:00,89	1
	Pass2	01:29,18	64	02:59,00	71	01:10,11	6	00:13,24	6	00:01,19	0
	Pass3	01:26,31	65	02:53,71	77	01:26,24	6	00:16,61	5	00:01,19	1
XFS	Pass1	01:58,41	50	02:57,32	73	01:39,05	5	01:18,94	4	00:00,03	94
	Pass2	01:59,78	50	03:00,29	71	01:36,56	6	01:21,12	4	00:00,03	93
	Pass3	01:58,92	50	02:56,80	73	01:41,00	5	01:16,53	5	00:00,03	97
Ext4	Pass1	01:01,81	92	02:54,03	78	00:12,78	37	00:02,68	62	00:00,75	99
	Pass2	00:59,38	96	02:54,68	77	00:13,29	34	00:01,83	81	00:00,78	99
	Pass3	00:58,96	96	02:50,13	82	00:08,92	51	00:01,75	98	00:00,74	99
Reiser4	Pass1	01:05,26	93	03:13,42	68	00:34,84	65	00:08,07	99	00:00,06	91
	Pass2	01:03,16	96	03:11,61	69	00:32,58	69	00:07,86	99	00:00,05	89
	Pass3	01:03,86	96	03:13,11	67	00:32,76	67	00:08,22	99	00:00,06	92
Btrfs	Pass1	01:13,09	91	03:27,91	63	00:21,43	53	00:11,98	94	00:00,23	98
	Pass2	01:14,55	91	03:30,20	62	00:21,54	54	00:12,93	93	00:00,23	99
	Pass3	01:11,67	91	03:36,49	63	00:25,06	46	00:09,85	99	00:00,21	99
Ext3	Pass1	01:07,19	85	03:07,47	79	00:24,43	20	00:01,31	97	00:00,56	97
	Pass2	01:07,73	85	03:08,37	78	00:24,06	20	00:01,26	98	00:00,63	99
	Pass3	01:11,67	80	03:08,81	79	00:26,43	19	00:01,36	99	00:00,62	99

Jak je vidět, celkově nejléve si vedla Ext4. V prvních třech testech zvítězila, i když v případě druhého jen velmi těsně s XFS a JFS. Ve třetím testu pak válcovala všechny FS. Až ve čtvrtém testu ji dokázala o malý kousek překonat Ext3. V pátém tesrtu pak s přehledem zvítězila XFS, nicméně rozdíly jsou jen v řádu setin vteřiny. Hodnocení využití procesoru je diskutabilní, nicméně dovolím so říct, že hodnoty nejsou nijak extrémní a v zásadě vyšší zátěž je vykoupena vyšší rychlostí prováděného úkolu. I když jsem byl povětšinou zastáncem XFS, po tomto výsledku dám na domácí NAS raději Ext4, která se jeví pro mé užívání vhodnější.

       

Anketa

Obrázky

Komentáře

[JJ]

Urob prehladne grafy, pls :)

[rudiik]

Spachal jsem jeden rychly graf, vzdy nejlepsi vysledek FS v danem testu. Bohuzel rozlisovaci schopnost u pateho testu je nulova Vecer pripadne muzu doplnit podrobneji pro kadzy test, pokud by byl zajem.

[Trained.Monkey]

Mozna by stalo za to udelat paralelni testy. Tedy spustit rozbalovani jadra 100x a sledovat ktery FS drive skonci.

[Semo]

Ak sa nemylim, ze cpu% znamena to, co si myslim, tak zataz CPU napr. pri rozbalovani kernel stromu bude samozrejme 10x vacsia pri procese, ktory trval 10x mensiu dobu. Nema ziaden vyznam merat cpu%, ale kernel time procesu (rovno z vystupu time, nebrat iba real).

[rudiik]

Ano CPU se zda byt presne tohle, alespon jak ho vraci time. To je take duvod proc nijak vyrazneji vysledku CPU nehodnodtim. Ohledne casu, byl bran kompletni cas provadene operace, protoze mne jako uzivatele zajima za jak dlouho to realne bude ne jak dlouho se s tim bude parat kernel nebo userspace. Time bezel ve verbose modu a pouzil jsem hodnoty 'Percent of CPU this job got' a 'Elapsed (wall clock) time (h:mm:ss or m:ss)'.

[Semo]

protoze mne jako uzivatele zajima za jak dlouho to realne bude ne jak dlouho se s tim bude parat kernel nebo userspace.

To ma naposledy zaujimalo na Didaktiku M. Odkedy mame multitasking, tak sa nepozeram na rozbalovanie jadra, ale vratim sa na ten terminal, az je hotovo a medzitym robim nieco ine. A otazka je, kolko medzitym stihnem "ineho". Pripadne ak pri kompilacii jadra zozerie skoro cele CPU len pohyb po fs, tak je prdu, ze ten pohyb je v absolutnom case o 20% rychlejsi ako iny fs (pretoze ten viac povedzme macha hlavickami), pri ktorom ale okrem pohybu zvladne CPU aj kompilovat (v case, ked caka na hlavicky). Takze cela kompilacia bude rychlejsia. Preto kernel-time ma vypovedaciu hodnotu, kdezto %cpu skoro ziadnu.

[Let_Me_Be]

Na stolni pocitac jedine JFS. Skvela odolnost vuci vypadkum (elektrika, hard freeze). Vykon je velmi dobry.

[kotyz]

LOL, prej skvela odolnost proti vypadkum! mel sem jfs jenom tri dny a jeste sem se rad vracel k ext3. za tu kratkou dobu sem mel asi 5 vypadku (dedek vyhodil svyma mocnyma strojema hlavni jistic) a z toho se mi asi 2x nebo 3x ztratili data (smazalo se nastaveni kdecek, konfiguracni soubory byly vynulovany). tohle se mi za nekolik let pouzivani ext3 stalo maximalne 1x nebo dokonce vubec. takze bych si nedelal o jfs zadny velky iluze (sice nemusi bejt chyba v nem, ale v tom jak si kdecka ty svy konfiguraky obhospodarujou, ale s ext3 to takovy problemy nedela). jinak ten vykon byl slusnej, to jo, toho sem si za tu kratkou dobu taky vsim, ale ty prazdny konfiguraky me vadili ...

[alblaho]

To jsou ty osobní nevypovídající zážitky

Myslím, že nejlepší je jít do nejobyčejnější, nejvíce nasazované a tím pádem nejotestovanější volby. Dnes je to Ext4.

Výhodou Ext4 je slušná rychlost. Já mám na starých instalacích roky ReiserFS, protože byl oproti Ext3 viditelně rychlejší. Nikdy nezaváhal, ale na novou instalaci bych ho nikomu nedoporučil pač je odsouzen k zániku.

Taky používám LVM. Ext4 je dobré, že se umí zvětšit bez unmountu a zmenšit. Ale z tohoto pohledu je pro mě zajímavé Btrfs, nicméně jsem konzervativní.

[kotyz]

ext4 trpel stejnym problemem, kvuli delayed allocation, v ubuntu na to meli nejakej patch do jadra kterej menil defaultni chovani a ostatni to pak myslim taky prevzali. a asi uz to ted funguje dobre, protoze sem uz dlouho necet zadny stiznosti ohledne toho ...

[Heron]

trpel stejnym problemem

EXT4 žádný problém v tomto směru neměl. To jen některé programy nesprávně spoléhaly na chování, které poskytoval pouze jeden jediný fs (v té době ext3) a pouze v jednom konkrétním nastavení (joural_data_ordered, commit=5). Jiný FS toto nedokumentované a v podstatě nezamýšlené (do 5s byla data, ne jen metadata, na disku) chování neměl a nemá a samotný ext3 v jiném nastavení (např. writeback, commit=600).

[kotyz]

uzivatele nezajima (me to taky nezajimalo, byl sem nasranej ze to musim vsechno nastavovat znova) co za to muze, proste sou data fuc a s ext3 se mu to nestavalo ...

spolehali na to, ze ext3 byl snad v kazdy distribuci default a i to data ordered bylo default. a liny programatori si na to zvykli a na budouci problemy bylo zadelano. a je snazsi vymenit fs nez kupu programu bez kterejch nemuzu zit (pokud je vubec za co je menit).

btw, jaka je v tyhle veci situace dneska? uz na to programy nespolehaji?

[Limoto]

Spíš se FS patřičně "přiškrtily"

[Heron]

Pokud mě paměť neklame, tak musely být splněny podmínky:

1. Tvrdý pád OS, nejčastěji z důvodu chybného HW
2. Blbě napsaná aplikace, co si není schopná ošetřit zápis důležitých dat na disk (a volání jádra na to jsou)
3. Konkrétní FS s konkrétním nastavením

ad 1. Snad k tomu netřeba nic dodávat. Pokud někdo přijde o data vlivem padajícího HW, na vině je HW.

ad 2. Dobře napsané programy nespoléhají na nedokumentované chování a pokud data na disku potřebují, tak si to zařídí. Což je odpověď na tvoji poslední otázku. Např. aplikace typy DB toto řeší dnes a denně. Pokud vyhovuje ACID, tak po úspěšném příkazu COMMIT tam ta data najdeš bez ohledu na to, co se s PC děje dál.

ad 3. Pokud někdo ("vývojář" aplikace) spoléhá (v podstatě to nemůže ani ovlivnit) na nějaký konkrétní fs s konkrétním nastavení, je jen dobře, že přijde o data. Mimochodem, v žádné normě není napsané, jak se má FS zachovat v případě špinavého odpojení. Pokud by se vytvořil nový čistý, tak ano, je to v pořádku.

Co nastalo. První dva body se snad ani neřešily (no Teo se k tomu vyjádřil na svém blogu) a jenom se udělal patch do jádra. Chjo. Takže takyprogramátoři teď mohou prasit vesele dál a když někdo přijde o data na jiném FS, tak za to samozřejmě může ten jiný FS. Tohle je cesta do pekla. To už můžeme rovnou mountovat s volbou sync.

a liny programatori si na to zvykli a na budouci problemy bylo zadelano. a je snazsi vymenit fs nez kupu programu bez kterejch nemuzu zit (pokud je vubec za co je menit)

Proč měnit. Ti "programátoři" mohou na místo, kde "řeší" to přejmenování souboru (změna metadat) vložit nějaké volání sync a mají po starostech. Osobně bych předpokládal, že už to mají hotové.

[kotyz]

a kdo je donuti tam to volani vlozit? mam si to snad vsechno delat sam (ikdybych to snad umel, tak by se mi do toho zrovna dvakrat nechtelo)? a v tech kdeckach 3.5.10 (ktery se budu snazit podrzet na disku co nejdyl to pujde) uz to asi nikdy nikdo opravovat nebude ...

[Atom321]

Nemají a nemohou. Ti "Programátoři" to tak měli a fungovalo to dobře. Ovšem, mocný hekr Teo pak v ext3 zprasil implementaci fsync(). Náběh aplikací, toto volání používalo, trval děsivě dlouho. Ovšem, chování fsync() na ext3 odpovídá normě, takže to dodnes nikdo neopravil. "Programátoři" aplikací (KDE, Firefox) byli nuceni to nějak řešit. Využili vedlejších vlastností obvyklých u Linuxových filesystémů, aby ten problém obešli.

Následně velký Teo v ext4 zcela nesmyslně upřednostnil rychlejší práci s dočasnými soubory před bezpečným uložením dat a tyto vedlejší vlastnosti (opět v souladu s normou) změnil.

Když ho uživatelé upozornili na vzniklé problémy, zaštítil se alibisticky normou a arogantně všechno svedl na chudáky aplikační programátory. Později až pod hrubým nátlakem nasraného davu to konečně opravil. Ovšem, svou chybu nikdy neuznal a ve stejném duchu dodržování norem bez ohledu na okolní realitu pokračuje dál, takže se máme na co těšit.

[Atom321]

uf, oprava: "...aplikací, toto volání používalo..." => "...aplikací, které toto volání používaly..."

[Aleš Kapica]

Nikdy nezaváhal, ale na novou instalaci bych ho nikomu nedoporučil pač je odsouzen k zániku.

Ale co to blábolíš? Reiserfs s námi bude ještě pěkně dlouhou dobu. Pravděpodobně si ho pleteš s Reiser4, co není v jádře a který zcela jistě nahradí Btrfs.

[Let_Me_Be]

Nevim jestli to dela i KDE 4, ale stare KDE ty konfiguraky pri aktualizaci vzdy mazalo, takze kdyz pak filesystem udelal rollback ty soubory proste neexistovaly.

[kotyz]

ale u ext3 s defaultnima volbama (ordered mode) to nebyl problem. a holt ty aplikace na to spolehaly a urcite na to nektery spolehaji dodnes. a kdyz to nedostanou a dojde k vypadku tak je pak zle nedobre ...

[Nicky726]

Ano dělá. Docela jsem se divil, jaká všechna SELinux oprávnění musí mít KDE programy nad svými konfiguráky, aby běžely.

[mike]

Uz nejaky cas resim v podstate totez (takove to domaci "HTPC" na kolene). Vykonnost fs jsem nijak nezkoumal. Chtel jsem tam prdnout ext3/4 nad soft mirror raidem (mdadm) nad 5400 pomalyma-uspornyma tusim Seagaty. Clovek prece jen o tu muziku a filmy nechce prijit, .... (Diskuzi o Raid+mdadm+mirror,atd.. nechme stranou, jde mi o neco jineho)

ALE: pri hratkach s MythTV jsem zjistil, ze to asi neni vhodne usporadani, protoze MythTv nahrava na co koukate (ziva telka). A to v kombinaci s RAIDem + Ext3/4 nedopadalo vubec dobre. Disky vydavaly opravdu nehezke disky. Chyby zadne. Vykon jsem nemeril, ale bylo jasne, ze takhle tedy ne.

Bohuzel uz si nepamatuji dalsi detaily, ale po nejakem zkoumani jsem presel na JFS, ktere melo nejakou vlastnost (mozna se musela zapnout ci postelovat), ktera chovani disku, resp. pristup k nim vyrazne vylepsila.

Samozrejme jde o aplikacni problem (MythTV), vse ostatni jelo uplne normalne. Souvisi to se zpusobem jak MythTv pracuje ( blabla kruhovy buffer blabla... vic si nepamatuju ).

Takze vzhledem k tomu, ze neni neobvykle v linuxovych koncinach provozovat MythTv na HTPC, tak tady je ma zkusenost a navrh na zarazeni MythTv do testovani FS. Evidentne ma pomerne specificky pristup k veci. Pripominam, ze to bylo pri nahravani videa nebo pri zive TV (je totiz nahravana take). Taky je mozne, ze v novych verzich MythTV uz to nejak poresili... Mozna, ze je to spis problem mirror soft raidu... nebo problem ext3/4... Ja to naposledy zkousel pred 3/4 rokem....jen jsem si na to vzpomenul, kdyz jsem videl ten titulek... nic vic... klidne me ignorujte jako neskodneho blazna...

[Roger]

LiveTV se nahrava kvuli timeshiftu - nekde se da nastavit, jak moc mista to ma zabirat.

[Kaa]

To uz se nenastavuje nejmin od 0.21. Ring buffer uz davno neni. Live se flaka do souboru dle EPG stejne jako nahravky .. vyhodu to ma v tom, ze kdyz dodatecne zapnu Rec, tak to z live spadne do nahravek, zmeni se jen atribut.

[pozortucnak]

Nevíte jak velkou výkonnostní ztrátu představuje u ext3/4 data=journal?

Potřebuji nějaké datové úložiště které by rychle startovalo(takže pokud možno žádný fsck) a které by vydrželo několik restartů za sebou...

Btrfs jsem vyloučil jako příliš experimentální, zfs přes fuse - to by výkonnostně dobré nebylo... a nakonec mě napadlo zkusit ext3/4 s data=journal...

[gtz]

Disky budete dávat do mirroru? nebo budou jen sólo? Dnešní kvalita těchto velkých disků stojí někdy za pendrek. Pokud budou sólo pro jistotu bych radil použít nějaké disky určené pro servery (RE nebo ES). Já bych asi na data volil nějaký FS, který se dá v případě nějaké havárie bezpečně obnovit v Linuxu. Právě u EXT4/XFS jsou tyto obnovy na pár dlouhých večerů.

[pozortucnak]

Disky budou sólo. S ext4 nemám žádné zkušenosti...

Stejně bych asi rád zůstal u ext3... Co je pravdy na tom že kontrola integrity dat je u ext4 rychlejší?

Ono zas o tolik nejde, je o počítač sloužící jako datové úložiště, s běžícím motion a časem s TV kartou vysílající do sítě...

[Limoto]

Co je pravdy na tom že kontrola integrity dat je u ext4 rychlejší?

Je to pravda a je to znát

[gtz]

Ono zas o tolik nejde, je o počítač sloužící jako datové úložiště

pokud půjde jen o nějaký NAS, tedy jen o nějaké úložiště, pak bych se klonil k EXT3. V případě nějakého průseru - pádu disků apod. kdy by se musely data nějak obnovovat u EXT4/XFS je to na hodně dlouho a spolehlivě se struktura neobnoví. Problém je i, pokud na EXT4/XFS náhodou něco smažete a pak zjistíte, že to budete potřebovat pak je to celkem problém. U EXT3 se to nějak dá obnovit.

[Limoto]

Dík za test.

[Non_E]

Jaké bylo nastavení jednotlivých filesystémů? Zajímá mě, co se z fs a disku dá vytáhnout maximálně, ne defaultně.

[Bedňa]

Ja osobne verím jedine stres testom, tie napodobujú reálnu prevádzku. Pred možno dvoma mesiacmi tu niekto na taký test hodil link. Ja z ReiserFS (nie Reiser4) som mal niekoľkonásobne lepšie výsledky ako ext4. Bez urážky test jednoúčelových operácií nemá z reálnou prevádzkou nič spoločné a ani žiadnu výpovednú hodnotu. Pozriem či som do tej diskuzie prispel ak áno, hodím sem link.