Názory k článku
Velký test osmi linuxových souborových systémů

U XFS se podle mě projevuje problém pouze při vytváření souboru. Operace typu "dekomprese portage", "kopírování portage" jsou dva takové příklady. Z toho mi vychází, že XFS zaostává pouze v případě, že je na daném souborovém systému potřeba často vytvářet nové soubory. Čtení souborů je OK a je dokonce rychlejší než u některých jiných systémů. Paušální tvrzení, že XFS vykazuje pomalou práci s malými soubory, nemá tudíž podle mě příliš smysl. Nejhorší nasazení XFS je podle mě pro kompilaci, v případě Gentoo tudíž více než /usr/portage bolí nasazení na místě, kam se dekomprimují soubory z distfiles a kde probíhá samotná kompilace. Ale článek je jinak podle mě docela fajn.

XFS se budu zabývat jedním z příštích článků, tak se mu ještě kouknu na zoubek. Ale máš pravdu, neměl bych dělat takovéhle závěry.

No já netvrdím, že má XFS excelentní výkon jinde (ikdyž ze stabilních systémů mu konkuruje podle testu pouze JFS), ale výkon přece není jediná vlastnost FS. Mám nepříjemné zkušenosti s Ext3 i s Reiserem, co se týče ztráty dat, takže zbývá XFS a JFS. XFS mě nikdy nezradil, s JFS zkušenosti nemám.

Tak to jste asi jediny, komu XFS neselhalo. Ve firme provozujeme starsi asi 60 TB pole, kde z historickych duvodu muselo byt instalovano XFS (v te dobe nic jineho pro takto velke kapacity pouzitelne nebylo) a realna zivotninost XFS je tak 5-7tydnu. Kompilovane jadro, moduly, s i bez initrd... nic nepomohlo. (Admin pracuje s linuxem a unixy asi 15 let, takze to neni mezi zidlickou a klavesnici). Denni tok dat 40GB zapis 800GB cteni, soubory 0.5-400MB. Jina pole, ktera pracuji s ReiserFS nebo ext2/ext3 jsou podstatne spolehlivejsi.
e.

Ja som pouzival XFS pre systemovy disk roky bez reinstalacie systemu a preformatovavania. Na particii boli robene len caste updaty systemu (gentoo). Particia bola mala, takze sa so suborovym systemom aktivne pracovalo. Ani raz sa mi nestalo ze by XFS ako suborovy system zlyhal. Pre datove uloziste som pouzival ReiserFS, vdaka ktoremu som bol schopny svoje data vydolovat vzdy. ReiserFS mi takisto ako XFS nikdy nezlyhal. Poskodil som si ho asi 2x a vzdy sam svojim nedopatrenim a nevhodnym softwarom.

Za nizkou zivotnost XFS ve vasem pripade muze byt nejaky sw, ktery neni kompatibilni se 64bit inode alokaci u XFS. SGI upozornuje napriklad na mozne problemy se zalohovacim sw. Zkuste se podivat na tento web http://oss.sgi.com/projects/xfs/training/index.html jsou to prezentace ze skoleni SGI o XFS. Je v nich dost zajimavych informaci, pripadne vas mohou nasmerovat jak nalezt a vyresit problem ktery s XFS mate.

Pouzivam XFS uz vic jak dva roky na nekolika discich a vse bez problemu.

+1, akorat 4 roky

Také jsem měl velké problémy s XFS. Použití na starším nicméně spolehlivém 100 GB disku v domácím systému, jako disk na který zapisují software P2P hlavně aMule. Obvyklá situace po cc5-8 hodinách provozu totální krach FS, nepřítomnost adresářů a jedině jak něco zachránit bylo umount, xfs_repair, mount. Také naprosto chybně hlásil velikost volného prostoru.

A nebude to zapnutym "barrier" optionom? Od cca 2.6.17 je by default zapnuty a spomaluje to hodne. Barrier je metoda, aby sa uistilo, ze data nezostanu len v diskovej cache, ale naozaj sa zapisu na disk. XFS to pouziva prave pri zapise zurnalu, tym padom sa to prejavi hlavne pri vytvarani/mazani spusty suborov.

Doplním kolem oběda.

ReiserFS i Reiser4 zobrazují obsazené místo správně, Portage strom je hromada malých souborů a ReiserFS a Reiser4 narozdíl od ostatních souborových systémů často dávají několik malých souborů do jednoho fyzického bloku. Říká se tomu tail packing. Díky tomu míň lépe využijí místo na disku za cenu trochu vyšší fragmentace. Btrfs nejspíš používá to samé. U mě na ReiserFS 3.6 du -h hlásí velikost Portage stromu 473MB.

Velikost portage je jiná u každého systému. Reiserfs a Reiser4 sice pakují ocásky k sobě, ale v tom případě by se to mělo blížit k těm 667 MiB ze shora a ne bejt takhle krutě pod skutečnou velikostí. Ale je možný, že se mýlím.

ee. Je tam naopak ohromne mnozstvi velmi malych souboru.

Chyba je v du, nie df.

du v pripade bloku, ktory obsahuje casti niekolkych suborov, tento blok rata kazdemu suboru cely, takze hlasi vacsiu velkost, ako je realne vyuzita.

Skutečná velikost Portage stromu (tedy počtu skutečně zapsaných bytů v každém souboru) je zhruba 160MB. du -h ti počítá po blocích a je mu jedno, že na Reiseru hromadu bloků počítá několikrát, protože v nich bydlí víc souborů najednou.

2.6.25-gentoo-r6, možná by bylo k ext4 férovější použít už 2.6.26

Ked som si ja studoval tuto temu - porovnanie suborovych systemov najviac ma zaujal tento clanok: http://www.debian-administration.org/articles/388
Okrem toho co je tu je tam aj merana zataz CPU a co by sa tu zislo tak aj kolko taka particia potrebuje nepouzitelneho miesta.

Jsem jediný, který na desktopu _nepracuje_ tímto způsobem? Kolikrát denně dělá uživatel operaci podobnou de/kompresi, kopírování atd. celého portage stromu? Procházení stromu ano, rewrite ano, ale tyto testy provedeny nebyly. A i kdyby byly, tak pokud budou rozdíly v řádu desítek sekund až pár minut, tak mě to na desktopu vůbec netrápí a patrně to nebude mít vliv na výběr FS. Alespoň ne u mne. Dělám totiž i jiné věci, než že čekám na dokončení operace.

Svoje testy jste zabil už v úvodu tvrzením, že stejně nikdo neví jak bude desktop používat za rok. Jinými slovy - ve výsledku je jedno co si kdo vyberete a tudíž to nechte na defaultním nastavení distribuce. A IMHO to není úplně nesmysl.

Co mě jako domácího uživatele zajímá je spíš bezpečnost dat na FS než jeho rychlost. Přežijou moje data při pádu systému? Jak dlouho potrvá nahození FS do provozního stavu? Na domácím počítači si většinou dovolím víc testovat než v serverovém prostředí a tudíž nějaký ten pád čas od času nastane.

Když už se rozhodnete dělat nějaké testy výkonu, tak by bylo vhodné se mrknout na výsledky jiných a pokud se někde dramaticky rozcházejí, tak to trochu analyzovat. Např. vaše výsledky mazání stromu jsou dost podezřelé. To se nemusí ani s ničím porovnávat.

Tolik (doufám konstruktivní) kritiky.

Což se nedá moc otestovat. Pračku můžete podorbovat zvýšené zátěži permanenetně, a čekat, kdy se jí něco rozčísne.
Ale dělat tohle létas FS (navíc stále s umělou zátěží, která nemusí prověřit slabá místa)... to není deterministické, takže i kdyby se vám nakrásně některé FS třeba za dobu jednoho roku podařilo rozbít, nebude to vůbec reprezentativní.

To je jen otázka kreativity (a matematiky) jaké testy vymyslíte, abyste dostal vypovídající výsledky.

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.

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.

Koláče sledovanosti? Já myslím, že sloupcový graf je pro tyto účely ideální, ale ta poznámka tam být mohla, i když je to IMHO jasné, že se jedná o čas.

Ahoj, nejak sem si nevsiml, jestli byly zapnuty bariery, nebo nebyly. Nebo byly zapnuty jenom selektivne.

Titulek na konci tohoto clanku Bariéry a žurnálovací souborové systémy

P.S.: Nedavno se o teto problematice psalo na abclinuxu v jadernych novynach. Protoze ruzni distributori zapinaji, nebo vypinaji bariery, podle sveho uvazeni a to ma docela zasadni vliv na vykon.

Typoval bych ze xfs bude mit bariery defaultne distributorem zapnute, protoze je to jinak system, ktery vyzaduje UPS, jinak muze dojit k poskozeni dat.

Všechny souborové systémy jsem nechával ve výchozím nastavení, takže opravdu nevím jestli bariéry zapnuty byli nebo ne.

Problem je v tom, ze defaulty pro ruzne distribuce, jsou ruzne. Takze i kdyz pouzivam Gentoo a muzu si tedy docela jednoduse zjistit, tak debianista, asi bude mit problem. Takze zkuste to zjistit, a doplnit, jinak to nebude mit pozadovanou vypovidaci hodnotu.

Btw. vzhledem k tomu, ze na Gentoo si vsechno kopilujete ruco, tak je docela odvaha, mluvit o defaultnim nastaveni.

???

aj tak vacsina ludi bude pouzivat to co je v ich distribucii default

jj, pouzivam ext3 protoze je v debianu default ;) experimenty me uz neba :D

Cože? Debián??? Já věděl, že jsem na něco zapoměl, "aptitude update; uptitude upgrade"...

kedze automaticke rozdelenie disku ponukane niektorymi "user-friendly" distrami som nikdy nepouzival, s niecim takym ako "default" som sa tusim ani nestretol (ono by mi to aj tak bolo viac-menej jedno, ostal by som pri reiserfs - ak by tam, pravda, nebola moznost pouzit reiser4 ;) )

Jojo, bohuzel ted mam ext3, protoze mi instalator tvrdil, ze z xfs zavadet nelze a reiserfs v nabidce nebyl :/
Jeste ze ostatni oddily a disky zustavaji.

pripad prvni:
dostal jsem v praci novy pocitac a tak jsem instaloval novy system (delam v debian unstable + kde 3), pri instalaci jsem zvolil xfs, protoze jsem mel s reiserfs na starem pocitaci trosku problemy, kompiloval jsem si vlastni kernel a nestacil jsem se divit, jak dlouho jsem musel cekat nez se smazaly (make mrproper) vsechny nepotrebne soubory po kompilaci. Zkousel jsem to porovnat s starym strojem (ktery je vykonove asi polovicni i diskove) a na starem stroji byl stejny kernel rychleji vycisten nez na novem stroji. Reinstaloval jsem na opet na reisera a uvidime jestli budou mit stejne problemy jako na stroji starem (ale tam je to mozne ze to bylo zpusobeno hw)

pripad druhy:
mailserver - tisice malych souboru, tam jsem bohuzel byl nucen prejit na xfs i za cenu ze budou vetsi systemove naroky (vetsi load) a pomalejsi operace. Na reiserfs mi bohuzel padalo, protoze mel problem se 600k souboru v adresari. Proste se system zhroutil a byl mozny pouze reset (ani reboot nebyl schopen zabit procesy ve stavu D), po rebootu nekolikahodinova oprava filesystemu (opravil to ale v poradku, chybelo jen par mailu, ktere se zrovna v tu dobu zapisovaly na disk).

Preferuji reiserfs3 (v4 jsem jeste nezkousel) pred xfs, na desktop bych zvolil reiserfs, ale bohuzel na server spise bych se priklanel taky k reiserfs, ale kdyz je potreba tolika souboru v adresari a vim ze reiserfs stim ma problem, tak nebudu riskovat. Tot muj nazor zalozeny na vlastni zkusenosti.

Ono XFS ma jeden dost zasadny problem - bezpecnost dat. Casom sa stracaju a zatial ani nejestvuje prostriedok typu fsck na urobenie poriadku na XFS particii. jedina moznost je prevytvorit XFS part nanovo. Na nepodstatne data je to v pohode - my to mame na par velkych squidoch - ked sa v squid logoch zacnu objavovat prilis casto hlasky o nedostupnosti suboru, ktory podla squid indexu dakde na disku zajvne ma byt, tak preformatujeme xfs a ideme dalej. Ale na projektove data... asi nie....

Zatim jsem se s timto problemem nesetkal, takze nemuzu soudit, ale pokud tenhle problem nastane, tak budu hledat jine reseni ve forme jineho fs.

Slysel jsem o tom ze pri vypadku napajeni se muzou tyto problemy objevit, ale zatim jsem opet nemel tu cest.

"...a zatial ani nejestvuje prostriedok typu fsck na urobenie poriadku na XFS particii. .."

to je omyl, existuje xfs_repair

Tak tak, jineka netketre distribude jej maji domrseny (xfs_repair), ale fedora a centos jej maji OK.

Ja netusim o cem to tu ohledne XFS trepete, seznam od nej utekl, podle me z hysterie, predtim na nem celou dobu jel.

Kupa zakazniku pouziva XFS na diskovych polich a v poradku, nekteri zakaznici debianu dokonce hlasi v kernelu 2.4 naprostou nestabilitu ext3, kdy pri velkem IO dochazi ke zhrouceni tohoto FS.

Ja uz ovsem na notebooku zazil, ze se mi soubory sekali na 1/2 a 2/2 byla zmresena, nastesti jenom nove, pomohl xfs_repair, kazdopadne stav, kdy se FS v rozvrzanem stavu pripojil a nezahlasil error, me moc nepotesil, po oprave uz se to neopakovalo.

Jinak velice stabilni je jiz ext3 s dir_index volbou

…ani reboot nebyl schopen zabit procesy ve stavu D…

Proces, který přežije výmaz RAM bych chtěl vidět :-)

pid=007 :)

Věc, co mi tu trošku chybí je zátěž jednotlivých FS na procesoru. Navíc bych rád viděl i chování ve více vláknech. Na serveru se obvykle nevytváří jeden soubor, ale třeba desítky vedle sebe. Test ukázal akorát jednu stranu mince, nicméně je pěkný. U toho přesunu by bylo zajímavější z jednoho fs, na druhý, protože takhle se akorát změní 2 inody a je celý strom přesunutý.

Zataz na CPU bude podla mna user+sys, zvysok bude cakanie na hw.

Ten clanok je sice super, avsak autor pozabudol na jeden velky detail s nazvom: Paralelny pristup k suborom. Myslim ze dnes je bezne ze v case X sa pokusa pracovat s FS viac nez jedna aplikacia. A v takomto pripade ukazuju jednotlive FS obrovske rozdiely. Ak sa nemylim, tak Reiser FS je super ak je pri citani z disku pouzity len jeden stream, avsak EXT3 ho hravo polozi na lopatky uz pri 3 streamoch. O viacerych ani nehovorim ...
Tento "detail" mi v teste dost chyba ....

On si to autor trochu "zjednodušil" specifikací, že půjde o desktopy. A přiznejme si, že valná většina uživatelů ten desktop používá jinak než s multiuser IO zátěží. Pro serverové prostředí by použité testy samozřejmě neobstály.

Souhlasim. Melo se to i testovat na soucanych PC s vicejadrovymi procesory.

No já bych spíš ocenil reálný test, když už je to na ty desktopy zaměřený. Např. pustit na pozadí nějaký audio/video přehrávač, vyvolat indexaci souborů, spustit nějaký ten automatický update, vypalovat cd/dvd a až při tomhle dělat ty testy. No ale zase by z toho lezly hodně rozdílný výsledky.

Ono to s tou XFS performanci neni az tak zle, da se podstatne zlepsit pouzitim spravnych parametru. Konkretne pomaha zvetsit velikost logu:

# mkfs.xfs -l size=64m,version=2 /dev/mapper/var

... a pouzit pri pripojovani vic log bufferu (muze se pridat i logbsize=64k nebo i vic pokud mate vytvoreny xfs ve verzi 2):

# mount -t xfs -o noatime,nodiratime,logbufs=8 /dev/mapper/var /var

Vice viz. staricky clanek o XFS tuningu a samozrejme `man mount` a `man mkfs.xfs`

"Performance"? To je mile. :-)

souhlasim, novejsi verze jeste podporuji lazy-count, takze doporuceny je toto:

#mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 /dev/neco

kdy agcount se da 2x pocet CPU, teda pro bezny dvojjadra = 4

jeste navic jsem videl: -s size=4096 a -i size=512

a mountovani pomoci:

#mount -o noatime,logbsize=256k,nobarrier /dev/neco /mnt/neco

prave nobarrier ma drasticky vliv na rychlost zapisu

Zajímavý test. Rád bych, kdyby měl pokračování. Dost by mě zajímaly odolnosti jednotlivých fs v případě výpadku proudu, nebo pádu systému. Zvolit nějakou vhodnou metodiku a fs moc nešetřit. Více než rychlost je v některých případech pro mě důležitější vědět, jak odolný takový systém proti chybám je.

To se dělá těžko tak, aby měly všechny stejné podmínky, takže by takový test nejspíš nebyl průkazný.

proste ext2 rulez

reiser4 umí pomocí pluginu i kompresi dat - pokud ji máte zapnutou, bude velikost portage ještě menší :-)
Škoda jen, že jste neotestovali spadfs. Ten by určitě vyhrál všechny testy.

Netestovali/nezkouseli jste nahodou nekdo ten SpadFS?

Tak jsem nakonec benchmark udelal sam a podelim se s vami. Potrebovali jsme ve firme zpracovavat v adresarove strukture obrovske mnozstvi malinkych souboru.

Vytvareli jsem skriptem 300000 souboru. Po kazdych 5000 vytvorenych souborech se vypsalo hlaseni, jak dlouho to trvalo.

U Ext3 to na zacatku ukazovalo 2 vteriny na 5000 souboru, postupne se to zpomalovalo a na konci to ukazovalo kolem 140 vterin na vytvoreni 5000 souboru.

Naproti tomu SpadFS na zacatku ukazoval 2 vteriny a na konci testu 6 vterin na 5000 souboru.

Tedy je videt, ze se SpadFS nezahlti malymi soubory, nezpomaluje se a svizne s nimi pracuje.

Samozrejme, jiny test by mohl vypadat uplne jinak, ale i jine benchmarky (napr viz tento graf) mluvi ve prospech SpadFS.

Ja tedy tomuto filesystemu fandim a Linus Torvalds taky. A mimochodem, vite, ze ten filesystem naprogramoval BLEK.?

Bravo BLEKu!!

A víte o tom, že stejně jako BLEK. mám pruchu osobnosti? Ale o proti něnu ji mám smíšenou - schizoidní a dissociální - proto také používám spadfs (zeptejte se bleka, co ta zkratka znamená :-))

Samozrejme, ze to vim - System pro Psychopaty A Debily :-)

Tak ja bych si pod uvedenym titulkem predstavoval neco trochu jineho (praci nekolika lidi kteri minimalne tyden opakovane podrobuji ruzne fs peclive pripravenym testum na ruznych hw platformach)...

Článek jsem odesílal s názvem "Test osmi souborových systémů".. Petr ho pak dokořenil. Já jen aby bylo jasné na koho to hodit :)

Cekal jsem, ze je to prace redakce.
Nechci tim nijak znevayovat Vasi praci, jen mi vadi bombasticke titulky...

Na druhou stranu já jsem taky redakce :)

zdravim,
mohli by ste prosim skusit otestovat reiserfs aj s mount option notail ( pripadne aj noatime), volne miesto sa sice prestane pocitat "spatne" ale vykon sa zdvihne
aj ked tail packing dokaze na mail/web serveri usetrit kopu miesta, v pripade ze ide o performance je to celkom brzda
tiez nie je zle vytvorit fs cez
mkreiserfs -s 16384 /dev/sdXX

Díky za pěkný test. Osobně mne vždy zajímalo, jaký je rozdíl mezi různými souborovými systémy a rychlostí spouštění programů. Před rokem jsem provedl několikanásobnou "čistou" instalaci z Live-CD Mandrivy 2007 - nejprve pro ext3, potom xfs a nakonec reiserfs3. Měřil jsem:
1. Dobu startu programů OpenOffice-Calc, Firefoxu a Konqueroru (10x "studený start" (vždy s restartem počítače, potom vždy 10x za sebou opakované spuštění programu), zvlášť pro každý souborový systém (time OpenOffice-Calc atd).
2. Dobu startu těchto programů v prostředí KDE, IceWm a IceWm+kdesktop, zvlášť pro každý souborový systém.
3. Celkovou dobu spuštění systému do grafického prostředí pro KDE, IceWm a IceWm+kdesktop.
4. Rychlost spuštění při použití xdm, Gdm a Kdm.
5. Zabraná paměť při startu xdm+KDE, Gdm+KDE, Kdm+KDE, xdm+ IceWm, Gdm+ IceWm, Kdm+ IceWm.
6. Co se stane při "tvrdém" restartu mezi různými souborovými systémy (vždy 10 "tvrdých" restartů).

Výsledky:
1. Doba startu programů mezi různými souborovými systémy byla téměř shodná, max. rozdíly byly do 0,2 sec. To bylo pro mne největší zklamání.
2. V prostředí IceWm a IceWm+kdesktop se programy spouštěly cca o třetinu rychleji než v KDE.
3. Nejmenší zabraná paměť byla u xdm (jaké překvapení...), Gdm o málo horší, Kdm byl "moloch" v porovnání s ostatními.
4. Tvrdé restarty "přežil" bez problémů extr3. U xfs mi přestaly fungovat některé programy, a skutečně některé soubory byly "nahrazeny" nulami. Na reiser3 už si bohužel z hlavy nevzpomínám.
5. Po zkouškách mi odešel zdroj (ani se nedivím, po tom počtu restartů...).
6. Volba byla pro mne jasná - extr3 a xdm+IceWm+kdesktop . Samozřejmě, pro nějaký specializovaný server se vybírají filesystémy jinak...

To by mě zajímalo jaký vliv má restart na zdroj PC :-D

no jo no, človíček asi vždycky vypínačem na zdroji vypnul a hned zase zapnul. takhle se nasral kamarád na visty a za chodu několikrát vypnul zapnul zdroj a taky to nepřežil

"a taky to nepřežil"

Kamarád nebo zdroj?

No napriklad taky, ze pri kazdom nabehu systemu je napajanie zatazene vyssim odberom diky rozbiehaniu diskovych zariadeni, kedy su ich odbery skutocne fascinujuce.
Ak mal uzivatel diskov v systeme viac, ani ja sa nedivim, ze ten zdroj tie restarty nevydrzal. Najma ak bol klasicky "skrinkovy" (lacny a dodavany spolu so skrinkou).
Ak by to bola niektora z "overenych" znaciek, tak by som sa skor divil ze odisiel.

Pod pojmem restart si představím reset tlačítkem na skříni, nikoliv vypnutí a zapnutí. Takže disky a HW běží vesele dál.

Nebyly ty restart ponekud zbytecne? Nestacilo by jen zabit Xka vcetne prihlasovaci demona (xdm, gdm, kdm ...) a zahodit vsechny cache (echo 1 > /proc/sys/vm/drop_caches), pripadne prepnout se jeste do runlevelu 1 a pak zase zpatky? Nedivim se, ze chudak zdroj odesel do kremikoveho nebe, neustale zapinani a vypinani a z toho vyplivajici tepelne soky nemaji polovodice moc rady, obzvlas ty vykonove ...

BTW: Jedinym zpusobem, jak zrychlit start okenniho prostredi a aplikaci v nem, je preloadnout je do pameti, zatimco pocitac ceka na prihlaseni od uzivatele (tak, jako se o to pokouseji Visty).

Pokud je dost pameti (tj. po beznem startu zbyva jeste stale nepouzita pamet), preload muze zacit uz pri primountovani /usr (nebo /, pokud je /usr na nem), bezi-li proces s nizkou I/O prioritou (ionice -c 3), nemel by nijak brzdit ostani programy.

Vysledny efekt se da nasimulovat tim, ze se pospusti vse, co se bude po startu poustet, a pak to zkusi jeste jednou znova (napr. zabije se Xserver). Pokud je start nacachovanych aplikaci rychlejsi (kdyz je dost pameti, vzdycky je), ma preload smysl. Skoda, ze zatim v jadre neni zadna snadno pouztitelna infrastruktura na snadne zjisteni, jake bloky se zrovna nachazeji v cache, na tohle by byla perfekni ...

U reiserfs se mi objevily kdysi nuly i tam, kde předtím byly normální soubory. To mi XFS nikdy neudělalo a tvrdých restartů jsem, díky problémům s HW zažil docela dost. XFS nemělo žádný problém. Mimochodem, nedal by se ten test dělat méně bolestivě na virtuálním stroji?

Pakliže nejsem jenom slepý, tak mi ve článku chybí jeden zásadní údaj a to z kolika opakování jsou uváděny střední hodnoty. Pakliže by hypoteticky byl každý test spuštěn pouze jednou, pak hrozí, že zde publikované hodnoty jsou statistickým nesmyslem. Ono vůbec by nebylo špatné uvěst také standartní odchylku jednotlivých opakování.

Jen tak pro porovnání by mě zajímalo jak by se v tomhle žebříčku umístilo NTFS (a pro legraci i FAT :)). Zkusili by to ještě testeři, prosím pěkně?

Oba velmi špatně – FAT je totiž na nic a NTFS má v Linuxu jenom userspace ovladače, které jsou pomalejší než ty jaderné. Kdysi jsem měřil NTFS ve Win a Reiser4 v Linuxu a stejně byl NTFS horší, a to dokonce o několik procent (bylo to přes pět). Výsledky jsem si ale nenapsal, takže je nemám :-(

5%? To je úplně o ničem. Jakmile není rozdíl aspoň 10% (lépe 15%) tak to je naprosto nezajímavé. Trochu se změní rozložení na disku a ulítne to o víc než těch 5%.

To je pravda, ten NTFS oddil byl cerstve naformatovany, takze to bylo mereno bez vlivu fragmentace. Nekdy bych mel ten test zopakovat.
Ale nejdriv me taky prekvapilo, ze je NTFS docela rychly.

Chtel jsem napsat …NTFS ve Windows.

a úpéesku k tomu :)

Zdravim,
zajimavy test ale mozna doplneni? Jaky byl pouzit scheduler ja pouzivam XFS skoro vsude (mailservery domino) a oproti ostatnim je o moc rychlejsi ( soubory se kterymi pracuje jsou mezi 1G-16GB ) a to je presne na co XFS by navrzen. Ale dramatickeho rozdilu jsem dosahle az zmenenim scheduleru

a na webserverech jedeme reiser(hodne malych souboru)

oba FS jsem uz rozbil(moje prace) a oba opravil...

kazdopadne na domacim pocitaci me vykon FS moc nezajima, ok pokud to cele neni 2x pomalejsi nez neco jineho ale par sekund me nezabije(jak uz nekdo psal).

Občas se stane, že počítač zdechne - ať už vinou napájení (zdechne UPS, nebo jsem blbec a UPS nemám, zdechne mi zdroj) a počítač v 10% případů prostě sám od sebe nenajede při obnově napájení - FS se z nějakýho důvodu nedokáže z problémů vymanit a např. specielně v případě ext3 si nechá odenterovat všechny ty inody, se kterýma člověk stejně nikdy nic neudělá a jen drží enter.

Jednoduchá otázka: který z testovaných FS je proti pádům na ústa nejvíce odolný?

Za sebe tvrdim, ze Reiser4 nebo JFS jsou prakticky nepolozitelne, zatimco ext3 se rozmlati po tretim kixu, nemluve o NTFS nebo FAT. Jini lide budou mit nazory diametralne odlisne, jelikoz pad se blbe dela tak, aby vysly dvakrat stejne podminky.

Dekuji za zajimavy clanek.
Chtel jsem se zeptat, zda by neslo udelat pokracovani s dalsimy zajimavymi testy, ktere jsem zde trochu postradal.
Napr:
- fragmenace a chovani pri fragmentaci (simulovat napr. postupnym zapisovanim do vice souboru - plnou paralelizaci bych nedoporucoval kvuli ovlivnovani jinymi faktory) a nasledne cteni / prepisy
- zkracovani a prodluzovani (opet z hlediska vlivu na vykon)
- prochazeni stromu (vyhledavani pres find, ls -lr ci jinac)
... tisic a jedna dalsi vec co se dela FURT

Vhodne by bylo asi bud zaznamenat nejakou 'realnou' zatez, pripadne si jich par vygenerovat a pak udelat mensi statistiku - jedna nahodna zatez je dost naprd.

Já neříkám, že by to nebylo zajímavé čtení, ale k čemu jinému než zábavě by to bylo? Tedy co si od toho slibujete?

Když si představíte, že byste za takový test měl zaplatit, zaplatil byste? Řekněme 500,- Kč? Vyplatilo by se vám to? Zkuste to vzít vážně a odpovědět ano nebo ne.

V jakem rezimu zurnalovani bezel ext3/ext4? Pokud v implicitnim (ordered), je to srovnavani hrusek s jabky, protoze v ordered rezimu poskytuje vyssi bezpecnost dat nez ostatni zurnalovane FS, ktere maji vesmes implicitne zurnalovani jen metadat (anebo plne zurnalovani vcetne dat, ale to je tak pomale, ze to nikdo nepouziva). To je taky ten problem XFS a vypadku napajeni, co se pise vyse v diskusi - pri zurnalovani jen metadat se presne tohle muze stat.

Pokud to byl skutecne ordered rezim, je to pro ext3/ext4 pekny vysledek. Uz aby vysly nove e2fsprogs, hned bych presel na ext4.

-Yenya, http://www.fi.muni.cz/~kas/blog/

Lze na některém ze systému realizovat dvoufázové mazání? Něco jako smazat = nastavit příznak smazáno a potom teprve podle potřeby provést opravdové mazání, naopak zrušením tohoto příznaku soubor obnovit?