Vlákno názorů k diskusi 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.