udaje v tabulkach mi prijdou divne. treba hned prvni: real 3m9.106s user 0m2.027s sys 0m27.775s. co se delo ty 3 a pul minuty kdyz to nebylo ani user ani sys? pak u "presouvani" a "mazani" mate casy skoro shodne 0.00nic - pri tom by se vam mela rozsvitit cervena kontrolka, to nic nevypovida. takovy test je potreba zmenit aby vykazoval porovnatelnejsi cisla nebo vypustit. vase zavery o xfs jsou podivne. jine testy (napr i vyse zmineny na debian-administration) rikaji neco jineho. stalo by za to zjistit proc se s nimi tak dramaticky rozchazite.
Ze by se ty tri minuty cekalo na IO disku? A tam pouzity FS taky zavazi, jak vhodne dokaze data na disku seskupit, nakolik se projevi interni fragmentace nebo naopak optimalizace typu "metadata blizko dat".
To je mozne, pak je soucasti testu zrejme take 'sync' a/nebo se jedna o zdrzeni na barierach - viz jine vlakno. Nicmene dalsi body meho prispevku by zaslouzily take komentar.
Ohledne mereni, to neni jen mozne, ono to tak skutecne je ;) Ten cas, ktery neni ani user ani sys, stravi process cekanim, a na jinak nezatizenem systemu pri mereni diskovych operaci to bude cekani na IO disku, nic jineho mi tam nesedi.
Jestli tam sync bude nebo ne zavisi od toho covlastne merime - jestli cas potrebny na fyzicke vykonani operace nebo jenom proste (logicke) vykonani operace s tim, ze syncronizace v dobe, kdyz je system idle, je prijatelna. Bohuzel podrobnosti toho "co vlastne merime" zaznamenany nejsou. Stejne tak bariery, zajima nas chovani systemu v "default" nastaveni, nebo optimalni vykon na vytunenem stroji? To by pak odpadli i komentare o mereni paralernich operaci.
Taky by sme mela vsechna mereni nekolikrat opakovat, aby se vyloucili chyby mereni (spravce pameti si zrovna v okamziku mereni zmysli, ze musi odlozit nejakou stranku do swapu a pod.).
Nicmene moje zkusenost je, ze pri intenzivni praci s malymi soubory (treba kompilace glibc a pod.) je reiser 3.6 skutecne radove rychlejsi nez ext2/3, s xfs zkusenosti nemam a proto ho ani komentovat nehodlam.
