Vlákno názorů k diskusi XFS vs ext3 při operaci "cp -al ..."

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.