XFS vs ext3 při operaci "cp -al ..."

Obecne je kazdy filesystem vhodny na neco jineho, tak bych se ani nedivil kdyby to tak skutecne vychazelo a u uplne jineho pouziti treba naopak.

Ale k tem benchmarkum:
1. Neni vubec uvedeno co to je za soubory, dokonce se obavam, ze jsou derave, coz muze celou vec komplikovat
2. Az na jeden test se v porovnani vyskytuji dost ruzne velke disky, coz muze mit vliv
3. U XFS vidime veliky rozptyl hodnot, u ext3 ne, chtelo by to zjistit proc
4. K tomu rozptylu jeste: mozna ext3 narazi na spodni hranici rozliseni, chtelo by to zvetsit objem dat
5. Neni tam uvedeno jadro systemu a dalsi dulezite veci
6. U sync neni nutne delat sudo
7. Statisticke veliciny se obvykle uvadeji i s namerenou odchylkou, ta tam sice nekde je, ale jen "usually around ..."

1. je to base systém Debianu, prostě nainstaluješ základní linux, plus pár základních balíků, konkrétně gcc, má to asi 200MB.

2. to je pravda, ale právě proto je to argument proti XFS, protože je pomalejší na všech typech disků

3. myslím si, že ty velké hodnoty u pc232 byly způsobeny 80% zaplněním, u malého zaplnení je na všech počítačích čas okolo 10s, fuji je laptop, takže má pomalejší disk. Jinak nevím, čím to je

4. bohužel, potřebuju, aby byl rychlý cowbuilder na překládání balíčků, takže měnit data nemůžu. Mužu ale měnit filesystém a přejdu na ext3.

5. jádra jsem tam doplnil, které další informace by mohly být užitečné?

6. pravda

7. nechtělo se mi s tím tak piplat, ale samozřejmě jsem každý test pouštěl mnohokrát, a jak jsem psal, liší se to tak do těch 10%, ale to proč je XFS 20x rychlejší se do chyby měření schovat nedá. Nejsme na praktiku z fyziky, tam by to asi šlo. :)

Hodilo by sa este ls -lR (aby sme videli, o jake subory sa jedna).

XFS neni moc dobre na male subory, specialne ak ich sypete vela za sebou via cp, pretoze ma asi 4 formaty adresarov: in-inode, leaf, node, B+ strom, ktore sa menia podla poctu suborov v adresari (a zakazdym sa struktura musi rebuildnut, co je vidiet pri postupnom pridavani suborov). Na druhej strane by bolo zaujimave vidiet, ako by to dopadlo pri extremne velkych adresaroch (> 16k suborov).

Druha vec, XFS drzi 2 B+ stromy pre volne bloky: jeden zotriedeny podla velkosti free blokov (lebo alokuje po extentoch, nie po jednotlivych blokoch) a druhy zotriedeny podla cisel blokov. Takisto dynamicky alokuje inody, vzdy po bloku 64 inodov (ext3 ich ma pevny pocet), tie tiez drzi v B+ strome. Takze prudke pridavanie malych suborov sa prejavi dost jasne (menenie 3 B+ stromov).

Dalej sa XFS snazi zapisy co najviac zpozdovat (az do nejakeho limitu), pretoze cim viac vie, co bude zapisovat, tym lepsie to dokaze rozlozit (ready su potom rychlejsie a v beznych situaciach ready prevazuju nad writami). Este pouziva jednu fintu: writebarriers, dokaze obist cache disku pri zapise zurnalu, takze sa nestane, ze by sa data stratili lebo disk ich mal v cache a nie este na platniach (neviem ale ci su writebariery implementovane aj v linuxe, podla toho co som vygooglil, vyzera ze asi hej).

Plus je mozne vybrat jeden z viacerych alokatorov (myslim ze su tri), kazdy je dobry na ine pouzitie.

Inak na dane pouzitie (cowbuilder) je fakt ten ext3 asi lepsi.

Mozno by este bolo zaujimave otestovat ext3 s >=80% zaplnenim (tam bude klesat rychlost hladania volneho bloku rychlejsie nez u xfs, ext3 pouziva bitmapy). IMHO je strasne tazke urobit skutocne vypovedajuci benchmark na xfs, pretoze je to hrozne zlozity fs. Na to je totiz treba podrobne prestudovat dizajn xfs aj ext3 a navrhnut testy podla toho (aby sa videly sily a slabosti v roznych situaciach).

BTW ten diametralny rozdiel medzi i386 a amd64 ma ale neskutocne prekvapuje...to uz zavana ze kompilator/optimalizacia spolu s architekturou maju nejaky zavratny podiel.

XFS nejvíc uškodilo to, že je to v podstatě IRIXový kód, který je obalený vrstvou, která překládá linuxové rozhraní na IRIXové.

Zatímco ostatní filesystémy jsou psané rovnou pro linuxové jádro.

Teda pánové, klobouk dolů:


ondra@pc232:/mnt$ sudo mount -o nobarrier /dev/sda2 /mnt/p1

ondra@pc232:/mnt/p1$ time sudo cp -al base.cow new

real 0m1.742s
user 0m0.028s
sys 0m0.288s
ondra@pc232:/mnt/p1$ time sudo rm -r new

real 0m1.773s
user 0m0.012s
sys 0m0.280s

Zkoušel jsem i

ondra@pc232:/mnt$ sudo mount -o nobarrier,noatime,nodiratime,logbufs=8 /dev/sda2 /mnt/p1

ale nepoznal jsem rozdíl. V obou případech trvá první kopírování 5s, další pokusy pak 1.7s. Pokud namountuju bez nobarrier, tak první cp trvá 12s, další pak 9s. Takže žádný 64bit vs 32 bit, ale nobarrier.

1.7s už by šlo, s tím už bych se smířil, ale proč to napoprvé kopíruje 5s, a s ext3 0.2, tak to mi vadí. No ale aspoň to prozatím vyřeším tak, že namountuju s nobarrier, tím se to podstatně zrychlí, a s přechodem na ext3 ještě počkám.

Našel jsem k tomu pár relevantních odkazů:

http://lkml.org/lkml/2006/5/19/33
http://www.nabble.com/mkfs-and-mount-tips--t3219440.html

Spis jsem to myslel tak, ze 3 & 7 dohromady by mohly neco odhalit. Napr. ze u XFS je vzdy vetsi rozptyl i pri stejne konfiguraci, nebo naopak.

No, vzhledem k tomu ze vetsina zdroju popisuje XFS jako vykonny, tak by me zajimalo kde udelali inzenyri z NDR chybu.

Moja skusenost je taka, ze XFS je naozaj pomalsie. Spociatku som ho pouzival pod gentoo na systemovu particiu. Jak na normalnom disku v desktopte, tak v USB ramceku s 2.5" diskom. Okrem toho, ze pri nekorektnych rebootoch sa vie XFSko zaujimavo dosahat a po spusteni fsck.xfs este viac su oba systemy na tychto diskoch dost pomale na to na com bezia. Na tom disku v USB ramceku som prehodil subory z XFS na ext3 a cely boot a aj stabilita (polorozhasene XFS po case) sa zlepsila, takze tak. Je mozne, ze XFS je lepsie na RAID poliach ale v beznom desktopte ho aspon ja uz nemienim pouzivat pokial ma zas niekto nepresvedci o opaku.

wget http://dakol.fsik.cvut.cz/~ondra/base.cow.tar.bz2


Pak sem napište zkušenosti, zajímalo by mne to. Díky.

Ještě malá poznámka - musí se to dělat jako root, protože tam jsou dev soubory.

Tak som to vyskusal, naozaj to spocivalo v tom barrier/nobarrier. Pre uplnost: testovane na 5400 rpm notebook disku Hitachi HTS541616J9SA00, ext3 59% z 15GB plna, xfs particia 93% plna z 11 GB pred testom (tj. prejavilo sa aj seekovanie, na skutocny benchmark by bolo treba rovnake podmienky):

xfs nobarrier:

time cp -al ../base.cow .; time sync

cp -al ../base.cow .  0.04s user 0.54s system 16% cpu 3.444 total
sync  0.00s user 0.04s system 25% cpu 0.144 total
cp -al ../base.cow .  0.02s user 0.55s system 17% cpu 3.244 total
sync  0.00s user 0.04s system 13% cpu 0.306 total
#v dalsom ma uz nacachovane bloky, kde su subory na hardlinkovanie
cp -al ../base.cow .  0.06s user 0.45s system 22% cpu 2.221 total
sync  0.00s user 0.05s system 23% cpu 0.216 total

time rm -rf base.cow ; time sync
rm -rf base.cow  0.02s user 0.28s system 10% cpu 2.716 total
sync  0.00s user 0.03s system 22% cpu 0.147 total
rm -rf base.cow  0.02s user 0.33s system 12% cpu 2.822 total
sync  0.00s user 0.05s system 18% cpu 0.256 total


xfs barrier:
time cp -al ../base.cow .; time sync                  
cp -al ../base.cow .  0.11s user 0.87s system 4% cpu 20.038 total
sync  0.00s user 0.05s system 15% cpu 0.327 total

time rm -rf base.cow ; time sync    
rm -rf base.cow  0.02s user 0.62s system 5% cpu 10.872 total
sync  0.00s user 0.00s system 0% cpu 0.315 total

ext3:
cp -al ../base.cow .  0.01s user 0.21s system 28% cpu 0.756 total
sync  0.00s user 0.01s system 0% cpu 0.738 total

rm -rf base.cow  0.01s user 0.11s system 83% cpu 0.143 total
sync  0.00s user 0.00s system 0% cpu 0.394 total

cp -al ../base.cow .  0.02s user 0.18s system 96% cpu 0.215 total
sync  0.00s user 0.01s system 1% cpu 1.280 total

rm -rf base.cow  0.00s user 0.14s system 94% cpu 0.148 total
sync  0.00s user 0.00s system 0% cpu 0.644 total

cp -al ../base.cow .  0.02s user 0.21s system 99% cpu 0.227 total
sync  0.00s user 0.01s system 0% cpu 1.108 total

rm -rf base.cow  0.01s user 0.11s system 97% cpu 0.122 total
sync  0.00s user 0.00s system 0% cpu 0.868 total

cp -al ../base.cow zase  0.03s user 0.19s system 95% cpu 0.226 total
sync  0.00s user 0.01s system 0% cpu 1.201 total

rm -rf zase  0.01s user 0.14s system 99% cpu 0.145 total
sync  0.00s user 0.00s system 0% cpu 0.794 total

Tj. xfs vysiel do 2x pomalsi pri copy, do 3x pomalsi pri rm. BTW ext3 pri mazani poloziek z adresarov trocha "podvadza", pretoze nezmensuje adresare (da sa to jednoducho otestovat vytvorenim adresara s 5000 subormi a potom tie subory zmazat, velkost adresara sa nezmensi). Toto spravanie je v ext3 uz hodne dlho, v podstate neviem, ze ci je to zamerna featura, ale davalo by to zmysel - moc miesta to nezabera a ked sa uz v nejakom adresari casto obmenuju subory, tak je pravdepodobne, ze jeho kapacita sa vyuzije.

Myslim, ze to nezmensovanie u ext3 sposobuje prave dirindex (nemoze zmensovat adresar, lebo by musel upravovat index), aj ked sa mi zda ze nezmensovanie adresarov bolo uz u ext2 (tam ich prekladal prazdnym miestom, ktore readdir preskakoval).

Ten dirindex je taka zvlastna spotvorenina B+ stromu (a,b-stromu?), ze sa nedokaze zmensovat, ale zase ma maximalne 2 urovne + 1 listova uroven (tusim to volaju H-strom). Co sa ale tyka vykonu, tak ten H-strom je asi rovnako ucinny ako B+ strom, akurat ma obmedzenie na max. pocet prvkov, co je ale 512^3=134 milionov pri 4k blokoch (+nejake drobnosti vyplyvajuce z toho, ze sa jeho vyska nezmensuje).

Imho fsck tie 'velke adresare' zmensovat nebude, ale neskusal som. Jednoduchy trik jak zmensit je vytvorit novy adresar, presunut tam subory, zmazat stary a premenovat na povodne meno. Ale nejak by som sa s tym nezatazoval, jednak tie adresare nie su moc velke, lookup podla mena je rychly (dirindex), readdir bude ok (prazdne miesta sa rychlo preskakuju a jadro robi read-ahead).

plus do tych prazdnych miest vo velkych adresaroch sa davaju nove subory, takze u "ziveho" adresara je to uplne ok.

Díky za vyzkoušení.

xfs nobarrier vychází cp na 3.4s na poprvé a 2.4s při dalších pokusech, nebo to špantě čtu? A ext3 0.7s a 0.2s, takže to je pořád 10x pomalejší.

Musis pripocitat sync time, je v druhom riadku.

xfs cp je okolo 3.6 a 2.5, rm okolo 2.9-3.0. ext3 cp je okolo 1.4 a rm je okolo 0.6-1.0 (tam to nejak kolise).

U xfs je 3.4 dvakrat, pretoze som medzitym umountil a primountil xfs a este kopiroval nieco ine, medzi 3.4 a 2.4 to bolo bezprostredne (prejavilo sa nacachovanie kopirovanych suborov).

Ale na ten cowbuilder sa rozhodne hodi viac ext3.

Na to sa treba spytat povodneho dotazovatela.

Ale v podstate sa kopiruju len nazvy a cisla inodov, takze to sa moc meni nebude, podla toho jak som pozeral ten obsah toho tar.bz2 suboru. Plus treba upravit v inodoch pocet linkov, ale tie su furt na rovnakom mieste. Takze kym cache nevyprazdni nieco ine...

To záleží, kolik balíků chci přeložit. Kopíruje se to na každý balík zvlášť. S tím syncem je to otázka, protože když to umí rychle okopírovat a pustit překlad, i když má třeba něco v keši, tak je to podle mně mnohem lepší, než když to trvá na začátku dlouho, protože se při překladu třeba zjistí, že je někde chyba v balíku, tak ji můžu hned opravit. V praxi pouštím cowbuilder většinou několikrát, ne třeba těsně za sebou, ale v keši si to udrží. Teď jsem to zkoušel:

time sudo cowbuilder --update

trval 38s a 35s, pak jsem namountoval / pomocí nobarier, rebootoval, a po restartu to bylo 27s a 12s. Teď je to stabilně 12s, když to pustím.

To ext3 ti trvá nějak moc dlouho, na třech mých počítačích to trvá 0.2s a sync 0.2.

ondra@august:/mnt/p1$ time sudo cp -al base.cow new

real 0m0.206s
user 0m0.012s
sys 0m0.152s
ondra@august:/mnt/p1$ time sync

real 0m0.277s
user 0m0.000s
sys 0m0.004s


Třeba to bude zase nějaký nastavení.

"To ext3 ti trvá nějak moc dlouho, na třech mých počítačích to trvá 0.2s a sync 0.2. "

Som to skusal na notebookovom disku a ten ma fakt nejake dlhe seek timy (subjektivne vyrazne pomalsi nez co mam na starsom desktope). Neviem kolkokrat to ext3 seekuje medzi zapisom journal<->data. U ext3 je default ordered mod, takze mozno to preseekovava casto medzi zapisovanim zurnalu a dat; som sa trochu hral aj s I/O schedulermi, ale vysledok to moc neovplyvnilo.

"Nemate to ext3 cp rychlejsi jen kvuli tomu, ze pouzivate dve ruzny partition? Blize k zacatku disku je rychlejsi. Ta moje je hned na zacatku."

Myslim, ze zavisi hlavne na velkosti partition, pretoze typicky su zurnaly na zaciatku (ext3, xfs), takze seek k journalu je rychlejsi na prazdnych a malych particiach. Inak xfs mam prvu - sda1, ext3 je na sda3. Mozno by bolo zaujimave dat docasne /var/log na tmpfs, zapnut logovanie zapisov (echo 1 > /proc/sys/vm/block_dump) a pozret sa, v jakom poradi sa tie bloky zapisuju.

Já jsem testoval různé i stejné partyšny, malé i velké a ext3 bylo vždycky rychlejší. Dokonce i na amd64 je ext3 o maličko rychlejší nez XFS na stejné partyšně.

Takže nevím, čím to je.

No zdravim panove.
Mam v praci fileserver (Debian Etch, vanilla kernel 2.6.23.9, CFQ scheduler).
HW: P4 HT 2,8GHz, 1Gb RAM, Intel ICH7 chipset, SATA II disky.
Mam 120Gb partition na sw raid1, XFS s noatime.
Particia sa pouziva prevazne na presuny velkeho poctu malych suborov [100.000 az 200.000, 100kB az 2Mb ale 60-70% skor blizsie k tym 200-300kB].
Subjektivne [cas som nemeral, nebolo zapotreby] XFS je znacne rychlesia ako Ext3 ktoru som pouzival
pred tym s takim istym ucelom a tiez na sw raid-1, ta ista masina.
Pre porovnanie - NTFS na serveri odkial tie subory beriem je neporovnatelne pomalsia.
Masina bezi uz polroka pri poriadnom zatazeni [Samba FS pre 60-70 zamestnancov a zalohovanie, DNS, intranetovy web, Zabbix, aplikacny server s vlastnymi app co zeru snad 80% cputime ] - a som s tym spokojny.