Test rychlosti souborových systémů z 2.6.32

Phoronix testoval pět souborových systémů ve verzích z jádra 2.6.32. Hlavní důraz byl kladen na srovnání Ext4 a Btrfs. Ačkoliv Btrfs porazil Ext4 ve většině testů, starý dobrý Ext3 se zase vytáhl oproti Btrfs. Kromě toho byly v testu ještě XFS a ReiserFS.

15.12.2009 10:18 | Robert Krátký | Zajímavý článek

Komentáře

[Michal Kubeček]

Už zase diskriminují JFS. :-(

[Amarok]

+1

[Michal Kubeček]

Jsem jediný, komu připadá nesmyslné porovnávat výkon filesystémů (nebo čehokoli jiného) podle toho, v kolika testech vyhrál jeden nad druhým?

[belisarivs]

Myslim, ze to ma spis informativni charakter. Pokud neni vykon priorita, tak se nebude vybirat nejrychlejsi fs.

Jinak, je to Phoronix.

[Michal Kubeček]

Jde mi hlavně o to, že i když už se porovnává výkon a pominu-li různou relevanci jednotlivých testů, je potřeba zohlednit, že nelze dávat stejnou váhu tomu, jestli v jednom testu vyhrál A o jedno procento nebo ve druhém B poměrem 2:1.

[Espinosa]

Pokud nevybíráš FS podle nějakého specifického parametru (tuning serveru?) ale jde ti obecně o co nejrychlejší FS (desktopový uživatel, potenciálně mnohem větší skupina) pak má.

Je možné zahrnout další parametry mimo rychlost - bezpečnost, journal, podpora v GUI nástrojích, licence - hádám, tady bude to dost vyrovnané, takže výkon (rychlost) je to hlavní co uživatele zajímá.

[Michal Kubeček]

Jenže výkon nelze porovnávat podle počtu čárek, v kolika testech byl rychlejší jeden než druhý. Když v osmnácti testech A rychlejší o jedno procento a ve dvou B dvakrát, znamená to, že A vyhrál na celé čáře?

[Espinosa]

Vidím váš návrh na "zprůměrování" výsledků. Pro mě to ale to ale není přednost.
Mě osobně NEzajímá FS který masivně exceluje v jednom parametru ale zaostává ve všech ostatních.
Mě zajímá systém, který poskytuje efektivní výkon ve všech oblastech, maximálně flexibilní FS, protože to je tak, jak využívám svůj počítač.

[Michal Kubeček]

Tomu, že je pomalejší o jedno procento, říkáte "zaostává"? Podle mne by především tam, kde se výsledky liší jen minimálně (řekněme do pěti procent), měly být brány jako "jsou na tom prakticky stejně". Jinak se dopouštíte stejné chyby, jako když budete odhadovat politické preference veřejnosti podle výsledků voleb do senátu (tj. s většinovým systémem).

[Espinosa]

> Tomu, že je pomalejší o jedno procento, říkáte "zaostává"?
To jsem proboha nikde netvrdil.

> Podle mne by především tam, kde se výsledky liší jen minimálně (řekněme do pěti procent), měly být brány jako "jsou na tom prakticky stejně"
Samozřejmě. Souhlas.

> Jinak se dopouštíte stejné chyby, jako když budete odhadovat politické preference veřejnosti podle výsledků voleb do senátu (tj. s většinovým systémem).
Preference veřejnosti bych podle toho neodhadoval, ale výsledky voleb do senátu ano.
Respektivě tady v Británii výsledky do parlamentu obecně ;)

[Michal Kubeček]

Preference veřejnosti bych podle toho neodhadoval, ale výsledky voleb do senátu ano.

Výsledky ano, ale někteří v tom hledají víc. Vzpomeňte si např. na komentáře a strašení heslem "13:0" po posledních krajských volbách. A tady jde o stejný princip: autor udělá deset testů, v devíti bude A o dvě až tři procenta lepší (v jednom B) a autor to okomentuje, že A zvítězil na celé čáře a je o třídu lepší. Přitom výstižnější by byl komentář, že rozdíly nestojí za řeč.

[thingie]

Já bych klidně šel do té úrovně, že i u výrazných rozdílů bych předpokládal sytémovou chybu v měření, dokud by nebyla vysvětlena nebo alespoň odhadnuta technická příčina. To sice samozřejmě klade nesrovnatelně vyšší nároky na autora, než jenom pustit benchmark a podle čísel napsat své žurnalistické dílo, ale apoň by to pak mělo skutečnou hodnotu.

[Petr]

Že vás to vůbec vzrušuje, test na serveru, který vezme desktopovou distribuci A final, B beta, C nějaký ani ne alpha snapshot a vyhlásí který distro je nejlepší na základě výkonu v PostgreeSQL (což je jistě killer desktop parametr). Já ty jejich testy beru silně s rezervou a to jsem to napsal hodně diplomaticky.

[Espinosa]

Já bych to vůbec shrnul - jasným vítězem je Ext3. Alespoň po zběžném pročtení článku. Trochu studená sprcha na očekávání ohledně Ext4.

[xm]

Ten výsledek je zavádějící protože Ext4 v 2.6.32 IMHO defaultně používá bariéry, kdežto Ext3 ne (ale je možné, že se pletu). Každopádně někde v 2.6.32 (nebo už možná 2.6.31, teď si také nejsem jistý) došlo k velmi drastickému snížení výkonu Ext4 (právě kvůli zvýšení "bezpečnosti" zápisu - mě to přijde pro desktop jako hodně špatná volba, ale co se dá dělat).

[Jiří J.]

Na Phoronixu je na konci napsáno:

Again, this testing was looking at the file-system performance when each file-system was left to its default mount options. EXT4 could be mounted in a way that it would not suffer as many performance penalties (at the risk of data being potentially lost in a crash) and the other file-systems can be tuned as well, but we will save that tuning and mount option testing for another article.

Brát benchmarky z Phoronixu jinak než informativně asi nejde , nicméně je kolikrát pěkné sledoval regrese výkonnosti mezi kernely.

[l4m4]

Brát benchmarky z Phoronixu jinak než informativně asi nejde

Jde. Coby humorný příspěvek do diskuse, jak se nemají dělat benchmarky...

[stativ]

IMO benchmarky mají perfektní a moc se jim toho vytknout nedá. To už ale nemůžu říct o závěrech z nich vyvozených.

[xm]

Souhlasím, Phoronix Test Suit je opravdu vymakaný balík benchmarků, něco takového na Linuxu dlouho chybělo.

Ale ty závěry, to je občas opravdu tragédie. Nicméně na letmé porovnání a hledání regresí mezi verzemi kernelu, různými verzemi ovladačů, atp. jsou ty benchmarky skutečně dobré. Jen si člověk musí udělat z naměřených dat vlastní závěry.

[Espinosa]

Víte o lepších benchmarks (huh, neodvažuji se to vyskloňovat)? Sem s odkazy!

[xm]

No na druhou stranu běžný uživatel žádné ladění parametrů filesystemu dělat nebude, takže pro něj ty výsledky (s defaultními parametry) docela relevantní jsou.

[Espinosa]

Do toho ještě dost mluví distribuce. Ale máte pravdu, že dafaultní nastavení by se mělo řídit touto filosofií. Z dob, kdy jsem si ještě sám kompiloval jádro, si pamatuji, že defaultní parametry jádra obecně se neřídily. Pokud by jeden šel podle nich, tak tak mu chybí podpora pro půlku HW, hlavně toho desktopového

[pht]

No na druhou stranu běžný uživatel žádné ladění parametrů filesystemu dělat nebude

A právě proto by mělo být všechno defaultně nastaveno na "safe" místo na "sorry".

Ono totiž v EXT3 je to s těma bariérama na posrání, protože každej fsync() synchronizuje komplet všecko, místo aby synchronizoval cache jen pro ten jeden soubor. Kdysi o tom byla někde diskuse, jak takový firefox na EXT3 může odpálit výkon systému jelikož ukládá historii do sqlite, které synchronizuje na disk (jako každá pořádná db) každou transakci.

Kdyby se raději distributoři místo těch šaškáren na novoty typu EXT* a reiser* kompletně vykašlali a používali nějaký normální a osvědčený FS (XFS, JFS).

[Michal Kubeček]

Kdyby se raději distributoři místo těch šaškáren na novoty typu EXT* a reiser* kompletně vykašlali a používali nějaký normální a osvědčený FS (XFS, JFS).

No jo, to je holt život. OpenSuSE 11.2 jako default nabízí ext4 a pokud v instalátoru zvolím JFS, dostanu kázání o tom, jak je nepodporovaný, neprověřený, netestovaný a vůbec.

[sxznam]

Phoronix šel do hajzlu od doby, co začli testovat na Blbuntu. Blbuntu má totiž vypnuté bariéry, aby vypadali hezky v benchmarcích. Nevím proč zrovna nezodpovědné nastavení Ubuntu by mělo reprezentovat výchozí nastavení Ext3.

[pht]

Aha, já si říkal jak je možné že nejšlendriánštější žurnálovací fs (ext3) je konsistentně mnohonásobně rychlejší než vše ostatní, včetně ext4.

Tak to je teda test pěkně na hovno. Zbytek FS totiž vychází dle očekávání plus mínus stejně.

[Ladicek]

Moment, ale v Ubuntu je defaultně ext4. Tedy přinejmenším v poslední verzi, kterou jsem instaloval, což už asi byla 9.10.

[Ladicek]

Aha, to je ovšem moje blbost. Nic jsem neřekl.

[Petr]

Škoda, že neotestovali SpadFS, ten by jim to natřel Škoda, že se masivněji neprosadil, je to docela zajímavej FS..

[Tom Galanda]

Ten Spad FS se ještě vyvíjí? Už hodně dlouho je na stránce projektu verze 0.9.10, občas tam kouknu (http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/spadfs/), ale nevidím další vývoj.

[cadic]

protoze se autorovi prohloubila porucha a prestal komunikovat (prej, psali to pod komixem na rootu)

[Z.]

A prej taky autor pise vlastni kernel...

[Pavel Půlpán]

A prej má autor vlastní psychiatrickou léčebnu, kde mu každý den minimálně dvakrát připomenou, že má poruchu osobnosti, aby na to náhodou nezapomněl...

[gtz]

Používal jsem na větší souborové systémy > 2TB systém XFS. Rychlost celkem solidní, jediným problémem bylo celkem pracné recovery v případě chyb.

[Michal Kubeček]

XFS jsem dřív používal na větší filesystémy, ale bohužel jsem narazil na velmi nepříjemný problém, objevující se hlavně na víceprocesorových systémech (stačí běžné dvoujádro) s větším množstvím paměti (2-6 GB). Nucené uložení obsahu cache na disk (např. příkazem sync) na takovém systému mi někdy trvalo až 40-50 sekund. Zákazem bariér se to trochu zlepšilo, ale i tak zůstaly celkem běžné časy kolem čtvrt minuty. Bohužel se tento problém projevuje i při vypínání virtuálního stroje běžícího pod VMware, VMware Workstation prostě "zamrzne", dokud se všechno nezapíše.

Proto jsem začal na větší filesystémy (a hlavně filesystémy s většími soubory) používat JFS a jsem s ním velice spokojen. Bohužel je tento filesystémem neprávem opomíjen, což je ostatně vidět i na odkazovaném testu, kam zařadili tři ze čtyř tradičních žurnálovacích filesystémů a dva nové, ale JFS vynechali.

[gtz]

Používal jsem to na velkých systémech (2xOpteron,2x8GB RAM,16x750 GB SATA,3WARE Escalade nebo Areca,2xDual GB LAN) a nesetkal jsem se s tím. XFS bylo celkem hodně rychlé.

Nevíte jak je na tom v dnešní době JFS s rychlostí oproti třeba EXT3/XFS ?

XFS jsem používal i v případě Enterprisse storage (FC DAS,16x SATA,Dual controller)apod. a spokojenost.

[pht]

Zapsat 6 GB za 50 sekund na disk není tak špatný výkon?

[Michal Kubeček]

2-6 GB byla celková velikost paměti, dirty pages podle /proc/meminfo nebylo obvykle víc než 50-150 MB. Typicky vycházela rychlost 1-3 MB/s, což na SATA disku není žádná sláva.

[Andrej]

Věčná škoda, že Reiser4 pořád ještě není kernelu. Snad ho tam Edward Shishkin už brzy protlačí, aby mohl všem ostatním řádně natrhnout pozadí.

[Aleš Kapica]

Já reiser4 používám. Udržuji si kvůli tomu vlastní lokální git repositář, neboť kromě reiser4 postrádám v hlavní větvi obladač k10temp pro čtyřjádrové phenomy.

Osobně jsem zaznamenal jeho výhodu především v tom, že..

• Opravdu velice rychle provádí kontrolu disku při ev. nekonzistenci dat a to i u hodně velkého a zaplácaného diskového oddílu. Navíc se mi (na rozdíl od reiserfs) u něj ještě nestalo, že by nějaké věci spadly do lost+found. Až mi to je podezřelé.

Naopak nevýhodou je že..

• Není v běžných distribucích. Kolikrát se totiž zapomenu a chci připojit externí disk co na něm používám reiser4
• Na rozdíl od reiserfs neumožňuje změny velikosti diskového oddílu.
• Při velkém zaplnění disku (cca od 80%) začíná jeho výkon při běžné práci rapidně padat.

[Tom K]

k10temp by mel byt na ceste do 2.6.33 (konecne).

[Andrej]

Já používám Reiser4 už nějaký ten pátek, kernel si kompiluju tak jako tak sám, takže jeden patch -p1 navíc mě nezabije. Jsem s ním spokojený. Skvěle funguje nejen na běžných discích, ale taky na DVD-RAM. Doba potřebaná k odmountování média klesne ve srovnání s UDF asi tak na třetinu. Samozřejmě má taky pár nevýhod. Jednou z nich je, že zaplnění oddílu spolehlivě uvede souborový systém do nekonzistentního stavu. Naštěstí to fsck.reiser4 dá do pořádku během několika vteřin, když už se to stane. (To jsou zkušenosti z doby, kdy jsem měl takový malý 4GB oddíl na experimentování. V praxi se asi dnes oddíly moc neplní nadoraz.)

[xm]

V praxi se asi dnes oddíly moc neplní nadoraz.

To byste se divil Za poslední rok se mi to stalo dvakrát (doma na 500 GB a 1 TB discích... a za chvilku bude potřeba další ).

[Michal Kubeček]

V praxi se asi dnes oddíly moc neplní nadoraz.

V tom vašem světě bych chtěl taky žít... :-)

[Amarok]

hehe, taky se pridam, skoro rok jsem musel umazavat z externiho disku kvuli fragmentaci (abych to drzel pod 80%), nez jsem si nakonec koupil 1,5 TB.