Linuxos filerendszerek 2008 elején - ahogy én láttam

Fájlrendszer, NAS, storage

Soha többet! Soha többet nem fogok filerendszer tesztet készíteni. Legalábbis néhány éven belül biztos, hogy nem. Ennél nagyobb szívás nincs a világon. Ahhoz, hogy az ember ne kapjon hamis adatokat, millió dologra kell figyelni:

  • single user
  • cron és egyéb feladatütemező, job, stb. letiltva
  • minden tesztet minimum háromszor futtani és a futások eredményeit átlagolni
  • figyelni arra, hogy sose legyen lemezre ki nem írt adat (echo "3" > /proc/sys/vm/drop_caches)
  • lehetőleg minden teszt futtatása előtt mkfs / mount
  • script-ből futatott tesztek egymást követő szakaszai előtt sync, sleep 10
  • a teszteket nem csak egy gépen végezni
  • a teszteket különböző block mérettel is futtatni
  • és még sorolhatnám

Ha a mérések elkészültek, akkor a tengernyi adatot összesíteni (lásd a lejjebb található spreadsheet táblázatok első oldalai), grafikusan megjeleníteni...

Ezek után nézzük mivel mértem:

Fu-Si Primergy RX330 S1

  • AMD Opteron 2210 1.8 GHz
  • 1 GB RAM
  • 3 x 73 GB, 3Gb/s, hot plug, 10k rpm, 3.5" SAS HDD
  • LSI RAID 128 MB

Fu-Si Econel 200

  • Intel Xeon 5110
  • 512 MB RAM
  • 2 x 160 GB SATA HDD

Benchmark programok:

  • tiobench
  • bonnie++
  • dbench
  • saját script

tiobench:
-----------

Linux filerendszerek 2008 elején
Fu-Si RX330 / tiobench / Rate (MB/s) / 4096 blokk méret

Linux filerendszerek 2008 elején
Fu-Si RX330 / tiobench / CPU (%) / 4096 blokk méret

Linux filerendszerek 2008 elején
Fu-Si RX330 / tiobench / Rate (MB/s) / 16384 blokk méret

Linux filerendszerek 2008 elején
Fu-Si RX330 / tiobench / CPU (%) / 16384 blokk méret

Linux filerendszerek 2008 elején
Fu-Si Econel 200 / tiobench / Rate (MB/sec) / 4096 blokk méret

Linux filerendszerek 2008 elején
Fu-Si Econel 200 / tiobench / CPU (%) / 4096 blokk méret

Linux filerendszerek 2008 elején
Fu-Si Econel 200 / tiobench / Rate (MB/s) / 16384 blokk méret

Linux filerendszerek 2008 elején
Fu-Si Econel 200 / tiobench / CPU (%) / 16384 blokk méret

Az összes mérési eredmény, számítás, diagram, stb. megtalálható ebben az OOo spreadsheet állományban.

bonnie++
------------

Az összes mérési eredmény, számítás, diagram, stb. megtalálható ebben az OOo spreadsheet állományban.

dbench:
---------

A dbench egy Samba szerver diszkterhelését szimulálja. A tesztek alatt 50 darab klienshozzáférést szimuláltam:

Linux filerendszerek 2008 elején
Fu-Si RX330 / dbench / 50 client / Throughput (MB/sec)

Linux filerendszerek 2008 elején
Fu-Si Econel 200 / dbench / 50 client / Throughput (MB/sec)

Az összes mérési eredmény, számítás, diagram, stb. megtalálható ebben az OOo spreadsheet állományban.

Saját teszt:
-------------

Mit csinál? Időt mér. Minek az idejét?

  • 3x mkfs
  • sync
  • sleep 10
  • 3x mount / umount
  • sync
  • sleep 10
  • 3x untar linux 2.6.24 tree / rm linux 2.6.24 tree
  • sync
  • sleep 10
  • 3x create / rm 10K files
  • sync
  • sleep 10
  • 3x create / rm 10K directories
  • sync
  • sleep 10
  • 3x create / cat / rm 1GB file
  • sync
  • sleep 10

A terjedelemre való tekintettel az részeredmények, eredmények és a script teljes futási ideje egyes filrendszereken file-okban érhetők el (az utolsó teszt minden file-ban):

Fu-Si Econel 200 - btrfs v0.11
Fu-Si RX330 - btrfs v0.11

Fu-Si Econel 200 - btrfs v0.12
Fu-Si RX330 - btrfs v0.12

Fu-Si Econel 200 - ext2
Fu-Si RX330 - ext2

Fu-Si Econel 200 - ext3
Fu-Si RX330 - ext3

Fu-Si Econel 200 - ext4
Fu-Si RX330 - ext4

Fu-Si Econel 200 - ext4 writeback
Fu-Si RX330 - ext4 writeback

Fu-Si Econel 200 - jfs
Fu-Si RX330 - jfs

Fu-Si Econel 200 - reiserfs
Fu-Si RX330 - reiserfs

Fu-Si Econel 200 - xfs
Fu-Si RX330 - xfs

Tanulságok:
-----------

  • Filerendszer tesztet készíteni nem könnyű.
  • Filerendszer tesztet készíteni rohadt unalmas.
  • Pontos filerendszer tesztet készíteni reménytelen vállalkozás.
  • Néhol megkérdőjelezhető a mérések pontossága, pedig minden egyes helyen megismétlésre került a teszt, ahol az eredmény kétséges volt.
  • Az eredményekből messzemenő következetetést nem lehet levonni.
  • Az embert érhetik meglepetések.
  • Az különböző terhelések esetén különböző filerendszerek lehetnek gyorsabbak.
  • Nem biztos, hogy azon a gépen gyorsabb a filerendszer elérés minden esetben, amelyik a nagyobbnak, erősebbnek látszik.

Mivel a tesztelések alatt, a nagy mennyiségű eredmények összesítésekor nem zárható ki az emberi tévedés, az eredményekért semmilyen felelősséget nem vállalok. Ha valaki kételkedik valamelyik mérési eredményben, legegyszerűbb, ha maga végzi el az ellenőrzést! Nem fog unatkozni :))

( Replaced | 2008. 02. 14., cs – 20:08 )

de hibaszazalekot szamolni megrosszabb! :D

--
Unix, Perfectly "natural" after five or ten years.

( pinyo_villany | 2008. 02. 14., cs – 20:14 )

szép és átfogó munka

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.18-opt1

( Nyosigomboc v | 2008. 02. 14., cs – 20:42 )

Azt nem lattam (lehet, hogy csak figyelmetlen voltam), hogy milyen OS/disztro, es milyen verzioju kernel.
Az utokor szamara erdekes lehet, mert elvileg kernelverzionkent valtozhat a sebessege, ha optimalizalnak valamit rajta.
Mik a mount parameterek? (pl noatime)

Ha ugyis scriptbol megy a teszteles, melyik resze az unalmas? Melyik reszevel van a legtobb szivas? (gondolkodtam regebben en is ilyenen, azert kerdezem)
----
Amikor a valtozas szele fuj, van, aki szelfogot epit, es van, aki szelmalmot. - kinai kozmondas
honlap készítés

"Azt nem lattam (lehet, hogy csak figyelmetlen voltam), hogy milyen OS/disztro, es milyen verzioju kernel."

OS: Ubuntu Hardy
Kernel: 2.6.24(-server)

"Ha ugyis scriptbol megy a teszteles, melyik resze az unalmas? Melyik reszevel van a legtobb szivas? (gondolkodtam regebben en is ilyenen, azert kerdezem)"

Szerintem állj neki és kiderül. Amit itt látsz, ami minimum 20-30 óra munka eredménye. A végén feladtam. Azért nem készült mindenről táblázat, diagram.

--
trey @ gépház

Szerintem állj neki és kiderül. Amit itt látsz, ami minimum 20-30 óra munka eredménye. A végén feladtam. Azért nem készült mindenről táblázat, diagram.
Jaja, valamikor nagyon rágen (amikor még a Reiser4 új volt és azt hitte mindenki, hogy lesz belőle valami) szórakoztam ilyenekkel, hogy fájlrendszereket benchmarkoltam, talán valahova fel is tettem ide a hupra, csak már a fene se tudja, hogy hol van. Szóval a lényeg, hogy jó sokat el lehet szöszmötölni vele és baromira félrevezető eredmények tudnak kijönni.
Tervezgettem egy időben, hogy kitalálok egy olyan benchmark suite-ot, ami egy 80GB-os vinyót telerak kicsi közepes és nagy fileokkal majd kb 90%-os telítettségnél elkezd random letörölni, appendelni, másolni stb és a lényeg, hogy közben folyamatosan rögzíti a teljesítményt. Így gyakorlatilag azt akartam lemérni, hogy valós környezetben mennyire fragmentálódnak a fileok az egyes filerendszereken és hogy milyen ütemben degradálódik a teljesítmény. Mert igazából szerintem ez az ami sok ember számára tényleg érdekes, nem pedig az, hogy egy zsír újan mkfs-elt filerendszer egy pár GB-os szintetikus teszttel mit tud.
Mondanom sem kell, hogy a projektből nem lett semmi, mert az jött ki, hogy reális eredményhez egy futás kb 50 óra lett volna és még így is túl nagy szórása lett volna az eredményeknek.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

( msandor v | 2008. 02. 14., cs – 20:52 )

Szép munka, köszönjük!

Ha jól látom, nem is olyan rossz az ext3...

--
by Mikul@s

( xobor | 2008. 02. 14., cs – 22:06 )

:-) Gratula & köszönet!

Ihletem van:

/ - ext3
/boot - ext2
/home - xfs
/var - reiserfs

( denes | 2008. 02. 14., cs – 22:10 )

Tenyleg szep munka! Koszonjuk.

- Use the Source Luke ! -

( anr | 2008. 02. 14., cs – 22:59 )

kellene egy angol forditas, es mehet digg/slashdot/...
mashol nem nagyon talalni ilyen reszletes munkat.talan nem veletlenul:)

--
Live free, or I f'ing kill you.

( dominis | 2008. 02. 15., p – 00:03 )

Ahhoz kepest, hogy autoszerelo vagy, egesz szepen ossze tudtad foglalni. :)

( horvatha | 2008. 02. 15., p – 00:11 )

Kösz, Trey!

Böngészgetem, szaglászgatom, érdekes.

Csak nem vagyok komoly szakértő, inkább afféle poweruser, aki a saját gépeit tartja karban, így nem látom át az egészet.

Valaki merészelne legalább részleges tanulságokat levonni ezekből? Tehát kijelenthetők ilyen "bölcsességek", hogy:

Feltéve, hogy Trey mérései helyesek, biztosak lehetünk benne, hogy:
a) Laptopra nem ajánljuk X, Y, és Z rendszereket, mert sok procit esznek
b) /home-ra Z rendszer ajánlott, mert hatékonyan kezeli a sok kis fájlt
...

Vagy bármi emészthető konklúziót lehet levonni? Persze, ehhez meg kell bízni az eredményekben.

Előre is köszi.

Sommás igazságot nem lehet mondani, mert marhán függnek az eredményként kapott számok attól, hogy a benchmarkokat milyen paraméterekkel futtatja az ember. Sokkal több teszt kellene sokkal több eredménnyel. Szerintem több hónapos tesztelés után lehetne valamiféle olyan következtetést levonni, amit többé kevésbé igaznak lehetne elfogadni.

--
trey @ gépház

( szdl | 2008. 02. 15., p – 01:40 )

Nagyon tanulságos. Gyakorlatilag mindegy, mit használ az ember, ha vegyes feladatra használja.
Szerintem nem csak a hardvertől, kerneltől, disztrótól stb. függhet, hanem pl. az aktuális széljárástól, páratartalomtól, pszichikai állapottól, Gyurcsány és Orbán beszédektől stb...

Komolyabban néhány benyomás:

1. Kár a reiserfs-ért.
2. furcsa a btrfs (nyilván még korai lenne nyilatkozni róla)
3. bátrabban lehetne használni bizonyos feladatokra az xfs-t és a jfs-t.

Sajna.
Reiserrol viszont ugy hallottam, (pl A'rpi is irta), hogy viszont eleg
erzekeny a hibakra. Ebbol a szempontbol meg az XFS jobb, arrol
pedig pozitiv recovery torteneteket olvastam.

Elismerem nekem szerencsere meg kopp-kopp nem kellett sem xfs-t sem resiert menteni. (Csak ext2-t de azzal lehetett izzadni :))

Így van. Összekeveri. A JFFS(2) egy Rad Hat cucc beágyazott dolgokhoz, a JFS pedig IBM eredetű (1 verziója AIX-on jelent meg, az újabb OS/2-n, Linux-ra OS/2-ről portolták).

Érdekes filerendszer összevetések a múltban:

http://www.osnews.com/story/69/Interview-With-the-People-Behind-JFS-Rei… (interjú, 2001)
http://fsbench.netnation.com/ (2003)
http://linuxgazette.net/102/piszcz.html (2004)
http://www.debian-administration.org/articles/388 (2006)
http://gongrc.blogspot.com/2006/04/filesystems-ext3-reiser-xfs-jfs.html (2006)
http://gavinblack.blogspot.com/2007/03/filesystem-benchmarks.html (2007)

A Reiser nyilván már a múlté (kár érte, bár egyesek szerint nem ("hibázik")), de az XFS és a JFS nagyon jól szerepelt mindig. Kár, hogy vsz. kevesen ismerik, használják ezeket.

(Érdekes, ahogy a régi nagyok (SGI, IBM) tudása tovább él a Linux világában is. Érdemes odafigyelni ezekre a gyöngyszemekre).

Régebben egy RedHat levlistán olvastam egy tesztet (sajnos már nem találom), ahol szintén az XFS-t hozták ki teljesítménygyőztesnek.
Ellenben úgy is tesztelték a fájlrendszereket, hogy kihúzkodták menet közben a vinyók tápját (csak a vinyókét). Ezen a durva teszten kizárólag az ext3 nem produkált fájlrendszer összeomlást. Adatvesztése az ext3-nak is volt, de a fájlrendszer megúszta.
Kíváncsi lennék a btrfs hasonló megbízhatósági tesztjére is, mert nagyon ígéretes fájlrendszernek tűnik.

Az XFS nekem is tetszik, de a GRUB nem nagyon szereti boot partíciónak. Remélem ez a teszt pár éven belül teljesen értelmét veszíti, mert addigra a HDD végleg nyugdíjas lesz. Az új felépítés viszont teljesen új file-rendszert követel majd meg.
Egyszer a gőzgépeket is csak lecserélték...

Tudom, de ha csinálok egy boot partíciót ami GRUB barát, (EXT2, EXT3, Reiser, stb.) akkor az égvilágon semmi baja sincs. De már vagy 6 éve nem teszek ilyet. Sőt, a disztribúciók nagy része is úgy fordítja a GRUB -ot, hogy nem támogatja. Ilyenkor a LILO a megoldás, de az nem éri meg az XFS -ért. Ha fordítok egyet magamnak XFS támogatással, akkor utólag megoldható, de az megint annyi tortúrával jár, hogy nem megyek bele.
De a http://hup.hu/node/50938 alapján az SGI talán belehomorít. Ha igaz, akkor az XFS kap még egy új löketet vagy utódot. Akkor talán támogatottabb lesz.

Koszi a tippet, talaltam a jfs-rol egy igen jo ertekelest, igy most par ora alatt migraltam az 'eles' 15GB-os / particiomat ext3-rol jfs-re, forditottam hozza uj kernelt, mar csupan az fsck mellozese miatt is megeri! Aztan majd kiderul...

Mellesleg a Frugalware -current-ben levo grub/grub-install jo nagyot hasalt rajta, igy felraktam a grub2 legujabb verziojat, azzal tudok bootolni is.

Semmi bugot, memory leaket, rejtélyesen eltűnt fileokat, sok file törlés közben furcsán elakadó processt, unable to handle kernel mode paging request pánikot nem tapasztaltál?
Szerintem kezdj el lottózni, mert megsúgom, hogy szupernaturális mázliszériád van, ha jfs-el ezt mind megúsztad!
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Az ominózus eset még a patch formában keringő jfs-sel volt, egy 5 gépes őssamba/win98 hálózaton. (ArcNET! Költséghatékonyság...) Utána a gép még ment hozzányúlás nélkül ~2 évet. Ha volt probléma, hozzám nem jutott el. ;) Paradox db-k voltak piszkálva rajta, és doc-xls-ppt fájlcsokrok üldögéltek itt-ott, nem egy heavy used cucc volt, bár a dolog főműsoridőben jelentkezett. Ezért emlékszem rá. :D
Jó indok volt a rohangálós para és a ~3 óra álldogálás az addig "nemfontos" szünetmentes mellett... Ruhabolt, ünnepek előtt, számlázó/bizonylatoló/raktározós programocskák álltak. Nem mertem visszaengedni a júzereket a tükör egyik felének kiemelése+pótlása és az fs ~szemrevételezésének végéig. Nem kellett archívot visszatölteni. :)

[szerk:]
Ja, elfogadom a mázliszériát. ;) Én is olvastam rettentő sztorikat a JFS-ről, viszont eddigi pályafutásom alatt linux alatt csak ext2-t és Reisert láttam szétszállni. 1szer és 1szer. Azóta csak a /tmp lehet(ne) ext2... :DDD (Ext2-ről tudtam adatbányászni, Reiserről nem. Mondjuk a Reisernél nem voltam eléggé "motivált".)

( naffeju | 2008. 02. 15., p – 15:37 )

arra van valami ismert magyarázat/okos tipp, hogy míg a szintetikus méréseken az xfs kiválóan szerepel minden téren, addig sambán csúnyán elhasal? lehetséges, hogy a sok párhuzamos I/O műveletet rosszul kezeli az implementáció (az XFS tervezőinek szándéka ellenére)? itt van konfigurációs mozgástér? esetleg journaling overheadből fakad?

UPD: a xfs és jfs rendkívül hasonló viselkedést mutat, ahogyan látom. az ext3 és ext4-nél is megfigyelhető, hogy samba alatt relatíve visszaesnek, de nem messze nem annyira. talán az xfs és a jfs implementációja gyenge?

UPD2: 64 bit vs. 32 bit címzés kezelése?:)

a két hardverkongif között miért vannak ekkora relatív változások? létezik olyan, hogy az egyik fs jobban kedveli a scsi vagy ata vezérlést?

---------------
mpu.buzz.hu

A tesztek után egy csomó kérdés merült fel bennem is. Volt olyan, hogy furán néztem az eredményekre, de amikor a teszteket reboot után, frissen formázott FS-en, stb. több alkalommal is megismételtem és mindannyiszor ugyanaz vagy nagyon közel ugyanaz az eredmény jött ki, akkor kénytelen voltam elfogadni. A tesztelés ezért is vett igénybe ennyi időt. Sokszor kellett ilyesmivel szórakozni. Én gondoltam arra is, hogy a benchmark programok tévednek itt-ott.

A jfs / xfs együttmozgást én is megfigyeltem. Voltak olyan tesztek (ha jól emlékszem a bonnie++ random create / delete) ahol a jfs és az xfs gyalázatosan lassú volt. Ez azt jelenti, hogy a több FS ugyanazt a tesztet x+-10% idő alatt futotta, addig az xfs és a btrfs 2x-3x idő alatt.

A hardverkonfigok közt nekem meglepő volt, hogy a sima SATA bizonyos körülmények közt lenyomja a SAS-t.

Mivel ennyi "érdekesség" merült fel és a többszöri tesztelés sem igazolta, hogy valami ordas hiba történt a tesztelés közben, el kellett fogadnom. Itt tippeltem pl. arra is, hogy az Intel Xeon alapú vas talán korszerűbb, mint az Opteron-os, de konkrét nyomozásokat nem folytattam.

Mindenesetre a btrfs fejlesztő Chris Mason figyelmét is felkeltették az eredmények és azt ígérte, hogy megpróbálja reprodukálni a környezetet és a teszteket.

Kíváncsi leszek mire jut.

--
trey @ gépház

A hardverkonfigok közt nekem meglepő volt, hogy a sima SATA bizonyos körülmények közt lenyomja a SAS-t

erre azt tudnám tippelni/mondani, hogy lehet a SATA driverek kiforrottabbak intel chipsetekhez

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.18-opt1

Egyrészt a szekvenciális írás, vagy olvasás meglehetősen speciális (általánosságban véve ritka) feladat, másrészt pedig érdemes lehet megnézni teszteket, az adatsűrűség növekedése és a sebesség között én nem látok ilyen egyértelmű összefüggést:
http://www.storagereview.com/Testbed4Compare.sr
(sort: maximum transfer rate)

Hogy pontosak legyünk a google tanulmány konklúziója az volt, hogy az interfész típusa (ezáltal közvetve nyilván a gyártó termékskáláján belüli különböző típusok) kevésbé volt jelentős, mint az egyes gyártók közötti eltérések és a gyártási év.
Tehát gyakorlatilag azt állította, egy gyártó egy időszakban általában véve egyenletes minőséget produkált a termékskáláján. Ami logikus, ha arra gondolok, hogy a kész termék meghibásodási aránya döntően a gyártónál alkalmazott minőségbiztosítási eljárástól függ. Pl, ha most veszek Hitachi Desktar vagy Ultrastar vinyókt, akkor hasonló meghibásodási rátára számíthatok.
Persze azt nem mondták meg (nehogy bepereljék őket), hogy melyik gyártó a jó, melyik szar, illetve, hogy melyiküknek mikor voltak rossz korszakaik.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

( crown v | 2008. 02. 16., szo – 17:35 )

Belegondolva a legfontosabb a felhasznalo (nem rendszergazda) szinten az uzembiztonsag, egyszeru kezelhetoseg. Hiba eseten a konnyu helyreallitas. Ezert nem fogok soha tobbet XFS kozelebe menni, mert meghalt a HD, es amikor probaltam, semmit nem lehetett belole kinyerni. ext3fs lehet lasabb, de sokkal 'praktikusabb'.