Názory k článku
Jak rychlý je váš souborový systém?

Mno, FAT32 sice nema zadne prava ani dalsi veci, jenze je znacne neefektivni, informace o souborech (tzv. metadata) jsou ulozena na zacatku disku, takze se pak musi hodne preskakovat pri cteni souboru atd. Ostatni zde zminovane filesystemy se snazi toto zefektivnit ukladani metadat blizko vlastnich dat a maji dalsi ruzne optimalizace.

Kokrétně při mazání velkého souboru bych viděl rezervy v linuxové implementaci. Proč se jeden hóóódně velký soubor na FAT32 dá v DOSu smazat "hned", zatímco pod linuxem to podle velikosti souboru může trvat viditelný zlomek sekundy ?

Připadá mi to, jako by si linux při mazání pečlivě procházel FATku a mazal v ní všechny záznamy o jednotlivých obsazených clusterech, zatímco DOS jenom "odznačí" začátek řetězce a má hotovo. Ale tohle je jenom můj dojem.

Mne na FAT32 beha rychle vyhledavani souboru. Napr kdyz z mc chci najit *.txt z celeho disku, tak je FAT32 vyrazne rychlejsi (velikost diku je srovnatelna :-)

To je dano tim, ze FAT ma jmena souborů ulozena v adresari pohromade, zatimco ext2 je ma v inode (pro kazdy soubor jinde). Je tedy treba nacist mene dat z disku.

ext2 ma take jmena ulozena pohromade, v i-node je az vse ostatni, jen ne jmeno

Sypu si popel na hlavu, mate samozrejme pravdu.

Asi pred 14 dny jsem prechazel na ReiserFS a nedalo mi to abych - sice ponekud lamaisticky - zmeril, jestli je pomalejsi nebo rychlejsi nez ma ext2... tedy, subjektivne mam pocit, ze je mnohem sviznejsi a jediny objektivny test bylo kopirovani 600MB velkeho souboru z ext2fs na ext2fs, z ext2fs na reiserfs a ext2fs>fat32... jasny vitez ReiserFS. Je ale taky pravda ze kernel se mi kompiluje asi o pul minuty dele nez predtim, mozna je to ale taky tim, ze ext2 jsem mel na zacatku disku a ReiserFS mam az po 8 GB :o). Howgh Mezon

Tak jsem myslel, ze se podivam, jestli na puvodni strane, nejsou grafy, nebo tabulky a nic - clanek se nejak nekona.

Jinak autorovi jednoznacne dik za preklad.

Spravny odkaz ma byt:

http://bulma.lug.net/body.phtml?nIdNoticia=626

Pani a co tak skusit HPFS z OS/2 ktory na Linux-e bezi velmi stabilne. Ja osobne s nim mam velmi dobre skusenosti. Podla mojich skusenosti bez problemov prekona ex2fs a o FATx ani nehovorim. Pracuje sa aj na podpore "noveho" fs JFS .. uvidime ...

Harier

HPFS je uz dosta stary (i kdyz dobry, aspon pod OS/2)... jenze vubec neresi prava, vlastnika ... takze ho nelze pouzit jako ROOT. ... snad jako FTP, WWW
HPFS uz nedoporuceje pouzivat ani IBM ... proto je tu uz hodne dlouho JFS (aspon pro OS/2)

Jojo, IBM uz vydala treti betu (0.3.1). Sam jsem na to zvedavy, tento fs znam z aixu a tam nam slouzi velice dobre.
BTW ona podpora pro HPFS je i se zapisem? Jsem asi zaspal :-) Je to uz davno co jsem tuto polozku sledoval (jako byvaly uzivatel os/2)...

Ano uz to chodi R/W posledna verzia driveru HPFS for Linux je tu http://hobbes.nmsu.edu/pub/incoming/hpfs_203.zip

Osobne se tesim na zarazeni XFS do jadra, podle toho, co jsem cetl jde o velice silny filesystem, ostatne kdo delal na Irixu, muze si
o tom udelat ramcovou predstavu (pouze ramcovou, stroje od SGI maji vyrazne vykonnejsi I/O subsystem nez PC). Hlavni vyhodu vsak vidim v proklamovanem mnozstvi nastroju pro praci s XFS.

Ja osobne uz druhy tyden jedu na XFS, pouzil jsem XFS na cely HDD, vcetne root, zvitezil u me predevsim kvuli utilitkam, ktere narozdil od reiserfs jsou v pripade poskozeni schopny postizeny filesystem opravit, take se jevil o neco rychlejsi, i kdyz na druhou stranu reiser usetril nejaky, ne zcela zanedbatelny prostor. Takze zatim jsem velice spokojen a cekam, kdy se mi toto betatestovani opet vymsti :-)

Napred jedno upozorneni. Puvodni spanelska stranka se kona, vejdete do hl. menu, pak na volbu "Los mas leidos" - nejctenejsi clanky a a zde uz clanek najdete. Primy odkaz fakt nefunguje, ale to vypada na problem serveru.
Jinak se taktez tesim na XFS v oficialni distribuci jadra.

Tak jsem si "pocetl" - prohledl tabulky. Chapu spravne, ze XFS je nejrychlejsi az na odstraneni cele adresarove strukrury ? Pokud je to tak, tak netusi nekdo proc ? Je problem v XFS, nebo v rm ?

Podla mna je FAT32 v linuxe pomala jednoznacne z dovodu zlej implementacie. Ako uz bolo spominane, zmazanie niekolko 100 MB suboru v dose trva zlomok sekundy, v linuxe trva niekolko sekund. Najhorsie je ale to, ze kopirovanie dat z/na FAT32 trvna NIEKOLKONASOBNE dlhsie ako vo windowse. Proste prevod FAT32<-> VFS niekto nakodoval len tak, aby to fungovalo. Odhliadnuc od nevhodnosti FAT32 pre unixy sa podla mna k rychlosti FAT32 nemoze nic porovnavat, uz len z dovodu jej jednoduchosti.

ja se naopak odvazuji tvrdit, ze to nebude pravda.
pokud by system mel celou FAT v pameti, pak mozna, ale jinak ona jednoduchost fatky vubec vyssi rychlost neslibuje, zvlaste jeli ulozeny soubor fragmentovany. FS s i-node mi prijde naopak pro vetsinu veci daleko efektivnejsi, proto ocekavam ze bude rychlejsi.
a to jeste nemluvime o tom, jak inteligentne jsou na FAT?? ulozeny dlouhe nazvy, proste FAT?? neni jednoduhcej fs ;)

No teraz si nemozem overit velkost fat, lebo som v linuxe, ale pre 4gb disk mi to pre 4kb velke clustery vychadza na 4MB :) To je pre dnesne velkosti cache pouzivane pre disky male cislo, takze fat moze byt cela v pohode v pamati. Myslim ze fragmentacia suborov s tym nesuvisi, pretoze pokial viem, aj v ext2 a dovolil by som si tvrdit ze vo vsetkych file systemoch (hoci sa muzim priznat ze neviem ako funguju reiser a xfs) vznika fragmentacia suborov, nakolko pri zvacsovani velkosti suboru sa jednoducho nove data nemusia vzdy zmestit na koniec suboru.

Vážení a milí. Pokud je můj postřeh "mimo mísu", tak mě prosím nekamenujte, ale často na disketě přenáším data (vebové stránky) mezi linuxem a windows. Pro neznalé podotýkám, že zpravidla jde o několik adresářů dost často s dalšími podadresáři) s množstvím souborů o velikosti řádově 10 kb. Pokud doma v Linuxu tyto soubory kopíruji, trvá to zpravidla znatelně rychleji, než když totéž činím v práci ve Win 98 (na výrazně lepším stroji). Ještě patrnější je to při mazání týchž souborů. Zajímavé je také to, že v linuxu se začně floppy mechanika ozývat až při kopírování, či mazání poměrně velkých souborů, ve win se mechanika ozývá pořád, nehledě na to, že systém v tu hvíli zpomalí natolik, že se na něm prakticky nedá pracovat.
IMHO ono se na něm moc nedá pracovat ani jindy, protože člověka pořád zdržuje naprosto nečekanými komplikacemi, ale to už je jiná pohádka :)

Heh, to bude tim, ze linux proste pouziva cache (diky mount/umount je to v pohode ostreno pred vyndanim s daty stake v cache). Pri umount si pak musite pockat az to cache vyprazdni (ale dela to inteligentne => celkem rychle). BTW pod dosem tehda smartdrv a ten celkem pomohl...

No, rekl bych, ze hlavni problem tohohle rozdilu bude v tom, ze Linux pouziva efektivni cache a opozdeny zapis na disky (i diskety)...