Levy I/O ja tiedosto operaatiot Windows vs Ubuntu

[Ux64]

Kun ei noita lehtien testejä aina jaksa, niin tein oman testin. Tulos oli totaaisen järkyttävä.

Luodaan ensin ja sitten tuhotaan tuhotaan 10000 kpl 1 kilotavun (1024 bytes) kokoista tiedostoa samaan hakemistoon.
 
Ubuntu:
 
Process finished!  @  2008-05-10 19:59:18.138880
And it was started @ 2008-05-10 19:59:17.535340
Time used 0:00:00.603540 for processing 10000 files

Vistalla:
 
Process finished!  @  2008-05-11 08:37:08.289000
And it was started @ 2008-05-11 08:35:31.725000
Time used 0:01:36.564000 for processing 10000 files
 
Hervotonta! 160 kertaa hitaampaa tai nopeampaa riippuu kummin päin asiaa katsotaan.
 
Samalla raudalla ajettu testi dual boot ympäristössä. Eihän tuo voi olla totta, mutta on se vaan!
 
Eipä ole suotta Windowssin nopeutta kehuttu.

En oikein tiennyt mihin tämän pistäisi niin pistin sitten tänne. Halukkaille on myös tarjolla python source.

[Tomin]

Samalla raudalla ajettu testi dual boot ympäristössä. Eihän tuo voi olla totta, mutta on se vaan!
Eipä ole suotta Windowssin nopeutta kehuttu.

Nyt en ymmärtänyt. Mitäs tuossa oli niin pahaa? Vista hävisi 01.36 sekuntia (?)...

[Ux64]

Nyt en ymmärtänyt. Mitäs tuossa oli niin pahaa? Vista hävisi 01.36 sekuntia (?)...

Tuota köh köh. Linuxin aika oli 604 millisekunttia kun WIndowssin aika oli MINUUTTI 36 sekuntia ja merkityksettömät jämät.

Jos venytetään tehtävää suuremmaksi. Päästään tulokseen että kun vastaava tehtävä kestäisi linuxilla vuorokauden se kestäisi windowssilla 159.9 vuorokautta. Silloin sillä alkaa olemaan jo merkitystäkin. Oletin että ero olisi voinut olla kaksin tai jopa nelinkertainen, mutta noin suureen eroon en mitenkään pystynyt uskomaan.

[muep]

Tuo riippuu kuitenkin hyvin paljon käytettävästä tiedostojärjestelmästä ja sen toteutuksesta. Vistan tulos on kieltämättä heikko, mutta tuo testaamasi tilanne saattaa vain olla sille hyvin epäedullinen. Lisäksi olisi minusta ollut oleellista suorittaa mittaaminen useilla tiedostojen koolla ja lukumäärällä, jotta nähtäisiin, millä lailla nämä vaikuttavat toimenpiteen kestoon.

Itse en yllättyisi, vaikka hakemalla löytyisi semmoinenkin asia, missä Vista on 160 kertaa Linuxia nopeampi. Ei sillä, että se niin erinomaisen hyvä on, mutta kun järjestelmät ovat rakenteeltaan hyvin erilaiset, ovat ne usein hyviä eri asioissa.

[Tomin]

Nyt en ymmärtänyt. Mitäs tuossa oli niin pahaa? Vista hävisi 01.36 sekuntia (?)...

Tuota köh köh. Linuxin aika oli 604 millisekunttia kun WIndowssin aika oli MINUUTTI 36 sekuntia ja merkityksettömät jämät.

Ai jaa...siis se oli minuutteja eikä sekunteja...

Jos venytetään tehtävää suuremmaksi. Päästään tulokseen että kun vastaava tehtävä kestäisi linuxilla vuorokauden se kestäisi windowssilla 159.9 vuorokautta. Silloin sillä alkaa olemaan jo merkitystäkin. Oletin että ero olisi voinut olla kaksin tai jopa nelinkertainen, mutta noin suureen eroon en mitenkään pystynyt uskomaan.

No se on kyllä totta. Eipä minua hetkau...hups...nyt pitää saada kaikki vahtamaan parempiin käyttiksiin tai M$ korjaamaan tuon , nimittäin ei ole kovin merkityksetön juttu kun Windows on niin tärkeä käyttöjärjestelmä viostaan ja puutteistaan huolimatta.

[Ux64]

Itse en yllättyisi, vaikka hakemalla löytyisi semmoinenkin asia, missä Vista on 160 kertaa Linuxia nopeampi.

Toki! Kuten monessa testissä on todettu todellisuus ja testit eivät vastaa tosiaan.

Tämä tuli vain esille koska käytämme yhtä järjestelmää jossa on suuria määriä pieniä XML tiedoja ja kirosimme niiden hidasta käsittelyä Windows 2003 serverillä. Prosessi on selvästi levy i/o (tiedostojärjestelmän aiheuttama overhead) rajoitteinen. Eli levy käy täysiä ja prossu lähes idlaa. Tuli vaan mieleen tehdä pienehkö testi kotikoneella jossa nimenomaisesti tutkitaan pienten tiedostojen käsittelynopeutta.

Periaatteessa sillä ei pitäisi olla suurta merkitystä onko tiedostot 64 tavua vai 4 kiloa. NTFS tosin sijoittaa MFT data rakenteeseen hyvin pienet tiedostot, joka voi vaikuttaa olennaisesti asiaan. Tosin silloinhan niiden pitäisi olla ns. hyvin käsillä.

[mgronber]

Luodaan ensin ja sitten tuhotaan tuhotaan 10000 kpl 1 kilotavun (1024 bytes) kokoista tiedostoa samaan hakemistoon.

Mitä tiedostojärjestelmiä käytit? Entä olivatko osiot samalla levyllä vai eri levyillä?

Jos sinua kiinnostaa nähdä yhtään enempää vaivaa niin voisit toistaa testin ainakin seuraavailla tiedostojärjestelmillä: ext3, reiserfs, jfs ja xfs.

[Ux64]

Mitä tiedostojärjestelmiä käytit? Entä olivatko osiot samalla levyllä vai eri levyillä?

Linux ext3 / Windows NTFS, samalla levyllä eri osiot. Jos eri olisi ollut pieni tuollakin olisi merkitystä, mutta kun ero oli noin iso, niin nuo pienet tekijät ei kyllä paljon vaikuta. Tuon NTFS:n saattoi kyllä arvata siitä että mainitsin MFT:n.

Käsittääkseni nuo ovat yleisimmät em. käyttöjärjestelmillä käytettävät tiedostojärjestelmät.

Retroajoista tulikin mieleen, että Amigalle oli muuten muistaakseni melkoinen läjä erilaisia tiedostojärjestelmiä, kuten myös erilaisia pakkaus ja salaus layereita. Ilmeisesti käyttiksessä oli hyvä tuki joustavuudelle.

[mgronber]

Mitä tiedostojärjestelmiä käytit? Entä olivatko osiot samalla levyllä vai eri levyillä?

Linux ext3 / Windows NTFS, samalla levyllä eri osiot. Jos eri olisi ollut pieni tuollakin olisi merkitystä, mutta kun ero oli noin iso, niin nuo pienet tekijät ei kyllä paljon vaikuta. Tuon NTFS:n saattoi kyllä arvata siitä että mainitsin MFT:n.

Kyllähän minä nuo molemmat arvasin mutta piti asia kuitenkin varmistaa.

Käsittääkseni nuo ovat yleisimmät em. käyttöjärjestelmillä käytettävät tiedostojärjestelmät.

NTFS ei välttämättä ole yleisin koska oman kokemukseni mukaan XP-koneet ovat usein tulleet levyt FAT32:lla formatoituna. Nehän on tarvittaessa helppo muuttaa NTFS-levyiksi Microsoftin tarjoaman työkalun avulla mutta epäilen vahvasti että tyypillinen Windowsin ostaja ei sitä osaa/ymmärrä/halua tehdä.

Ext3 lienee Linuxin puolella yleisin mikä on omalla tavallaan varsin hämmentävää. Oman käsitykseni mukaan se on tarjoamastani nelikosta (ext3, reiserfs, jfs, xfs) heikoin suorituskyvyltään.

Retroajoista tulikin mieleen, että Amigalle oli muuten muistaakseni melkoinen läjä erilaisia tiedostojärjestelmiä, kuten myös erilaisia pakkaus ja salaus layereita. Ilmeisesti käyttiksessä oli hyvä tuki joustavuudelle.

Ei niitä minun muistaakseni hirveästi ollut. Tiedostojärjestelmistä muistan äkkiseltään kolme eli OFS, FFS (FastFileSystem) ja SFS (SmartFileSystem). Yleisin ainakin A1200-mallin aikaan oli FFS ja nopein noista oli SFS. Varmasti muitakin tiedostojärjestelmiä oli mutta ei niitä minun mielestäni hirveästi ollut. Salausjärjestelmiä muistan nähneeni yhden ja senkään nimeä en nyt suoraan muista.

[Jula]

Koittakaapa tuhota esim. yksi pikakuvake työpöydältä Vistassa... 10 sekunttia parhaimmillaan.. tai pahimmillaan

[Ux64]

Koittakaapa tuhota esim. yksi pikakuvake työpöydältä Vistassa... 10 sekunttia parhaimmillaan.. tai pahimmillaan

Jep, on tullut huomattua. Juuri siksi testin halusinkin tehdä. Kun tiedän että Vista on sika hidas. Mutta Ubuntun nopeus siis oli se mikä järkytti.

Mistä muuten johtuu että Ubuntulla tiedoston koko vaikuttaa aivan selvästi deletoinnin nopeuteen. Tusin fileiden unlinkittäminen on sentään niin raskasta, vai onko? Joskus roskakoria tyhjentäessä on tullut ihmeteltyä että mikä maksaa?

[UbunTux]

Joo itsellänikin ext3, kun tiedostolla on kokoa päälle giga niin topista pystyy helposti havaitsemaan rm:n. pitkään(no laitetaanpa time eteen).

Olen hieman katunut tuota ext3 valintaa, kun xfs on kuulemma parempi suurille tiedostoille, kun tuo digitv hörppii kiitettävästi levytilaa ja uudelleenpakkaus kunnolla tehtynä operoi levyllä aika paljon (esim. demuxaus). En kuitenkaan jaksa alkaa formatoimaan. Kannattaisiko?

[Ux64]

Olen hieman katunut tuota ext3 valintaa,

Siis kun olen tutkinut eri filesystemit, niin kyllä ext3 on teknisesti erittäin vanhahtava ja yksinkertainen. Melkein tulee journaloiva fat32 mieleen. Mutta onhan fat32 paljon nopeampi kuin ntfs kun poistetaan fragmentoitumis-ongelma. Senkin poistaminen tapahtuu pääsääntöisesti valitsemalla allkoitavalle datalle sopiva paikka. Eli fat32:ta voisi myös optimoida rikkomatta yhteensopivuutta.

Nonii jopas meni horinaksi. Mutta kuitenkin, ext3 on mielestäni vanhahtava eikä siitä tarvitse sotaa synnyttää. NTFS on sitten taas raskas. mm. siitä syystä sitä ei usein käytetä usbi-tikuilla, vaikka nekin rupeaa olemaan aika kiitettäviä. Ostin just backuppia varten muutaman mahtitikun että pääsi eroon kirotuista dvd levyistä.

Periaatteessa tykkään säätää ja tutkia sikana, mutta raja menee kyllä jossain. Ei jaksa koko systeemiä ruveta tuunailemaan eri tiedostojärjestelmien vuoksi. Lisäksi kotikoneen levy I/O:sta suurin osa on käyttiksen io:ta. Muulla on loppujenlopuksi hyvin hyvin vähän merkitystä.

[mgronber]

Mistä muuten johtuu että Ubuntulla tiedoston koko vaikuttaa aivan selvästi deletoinnin nopeuteen. Tusin fileiden unlinkittäminen on sentään niin raskasta, vai onko?

Väärä kysymys. Oikea kysymys on miksi ext3-tiedostojärjestelmällä tiedoston koko vaikuttaa selvästi sen poistamisen nopeuteen? Esimerkiksi jfs on tässä suhteessa täysin toiselta planeetalta.

Vastaavasti voi ihmetellä miksi reiserfs on niin hidas mountata suurilla osioilla.

[mgronber]

Olen hieman katunut tuota ext3 valintaa, kun xfs on kuulemma parempi suurille tiedostoille, kun tuo digitv hörppii kiitettävästi levytilaa ja uudelleenpakkaus kunnolla tehtynä operoi levyllä aika paljon (esim. demuxaus). En kuitenkaan jaksa alkaa formatoimaan. Kannattaisiko?

Itselläni on DigiTV-tallennuksia varten JFS-osio. Tässä testissä todettiin XFS parhaiten tiedostopalvelimeen sopivaksi. XFS:n edut JFS:ään nähdet tulivat esiin suurilla hakemistopuilla ja useilla vaihtelevankokoisilla tiedostoilla. Osion luominen, mounttaus ja unmounttaus sekä operaatiot suurilla tiedostoilla sujuivat molemmilla tiedostojärjestelmillä varsin tasaväkisesti, mutta JFS käytti vähemmän prosessoriaikaa kuin XFS.

DigiTV-tallennuksia varten sekä JFS että XFS vaikuttavat varsin tasaväkisiltä. Rohkenen jopa väittää että JFS voisi olla tässä tarkoituksessa jopa hieman parempi.

[peran]

Olen hieman katunut tuota ext3 valintaa, kun xfs on kuulemma parempi suurille tiedostoille, kun tuo digitv hörppii kiitettävästi levytilaa ja uudelleenpakkaus kunnolla tehtynä operoi levyllä aika paljon (esim. demuxaus). En kuitenkaan jaksa alkaa formatoimaan. Kannattaisiko?

Joo, olet oikeassa: xfs on parempi suurille tiedostoille. rm - toimii nopeammin suurilla tiedostoilla ja levytilaa on muutenkin enemmän, kuin ext3:ssa. Siis molemmat ovat ihan merkittäviä eroja ext3:een nähden.

[Timo Jyrinki]

Ext3:ta on kai kohtuullisen paljon optimoitukin, siis jottei se häviä muille Linuxissa käytetyille tiedostojärjestelmille ihan niin paljon. Ja tosiaan Windowsin käyttämiin tiedostojärjestelmiin verrattuna ei ole mitenkään hidas. Isojen tiedostojen poistaminen on hidasta kyllä tosiaan, muun muassa.

Mutta mikäs ext3:n vaihtoehdoksi? Susea käyttäessäni paloi hermot reiserfs:ään (sitten kun selvisi että se oli syypää), kun n. 150 gigatavun osion liittäminen kesti n. 15 sekuntia joka bootissa - ei luultavasti haluta että esim. peruskäyttäjän 500 gigan kovalevyn liittäminen kestää käynnistettäessä konetta esim. minuutin? Epäilen, kuten myös moni muu, että yksi kovalevyn korruptioista ei ollut laitevika vaan reiserfs:n bugi. Xfs taisi olla se joka hajoaa levytilan täyttyessä (ei ilmoita mitenkään, tallentaa muistiin yli menevät tiedot) tai virran katketessa? Eli suunniteltu ihan eri ympäristöihin joissa virta ei katkea eikä levytila lopu Reiserfs4 olisi mielenkiintoinen, muttei valmis. Jfs... no, se voisi olla mielenkiintoinen, tosin joissain benchmarkeissa ei ihan yhtä paljon ext3:ta arempi kuin xfs, ja olikohan senkin kanssa jotain perustavalaatuista ongelmaa...

Eli oma käsitykseni ainakin on, ettei vaihtoehtoja ext3:lle yksinkertaisesti ole, jos mietitään yleiseksi valinnaksi sopivia vaihtoehtoja. Ext4 vaikuttaa vahvimmalta kandidaatilta ext3:n korvaajaksi, joten voi vain toivoa että se tulee olemaan kilpailukykyinen xfs:n, jfs:n ja reiserfs4:n kanssa... niin ja zfs:n, jota ei ole Linuxille ja jota en ole benchmarkeissa kovin paljon nähnyt.

[mgronber]

Ext3:ta on kai kohtuullisen paljon optimoitukin, siis jottei se häviä muille Linuxissa käytetyille tiedostojärjestelmille ihan niin paljon.

Kuitenkin se häviää selvästi...

Ja tosiaan Windowsin käyttämiin tiedostojärjestelmiin verrattuna ei ole mitenkään hidas. Isojen tiedostojen poistaminen on hidasta kyllä tosiaan, muun muassa.

Etenkin kun nopeuden lisäksi ottaa huomioon tiedostojärjestelmän muutkin ominaisuudet kuten fragmentoitumisen ja vikasietoisuuden.

Mutta mikäs ext3:n vaihtoehdoksi? Susea käyttäessäni paloi hermot reiserfs:ään (sitten kun selvisi että se oli syypää), kun n. 150 gigatavun osion liittäminen kesti n. 15 sekuntia joka bootissa - ei luultavasti haluta että esim. peruskäyttäjän 500 gigan kovalevyn liittäminen kestää käynnistettäessä konetta esim. minuutin?

Minulla kesti 465 GiB:n (~ 500 GB) levyn liittäminen karvan verran alle 25 sekuntia. Kuinka kauan tuolla 150 GB:n levyllä kestää ext3:n määräaikaistarkistus? Kauankohan se kestää 500 GB:n levyllä? Oma tuntumani on että ext3:n keskimääräinen liitosaika on moninkertainen reiserfs:ään verrattuna mikäli tuo määräaikaistarkistus otetaan huomioon (ja mielestäni se pitää huomioida).

Jos kone toimii esimerkiksi palvelimena niin reiserfs vaikuttaa selvästi paremmalta kuin ext3. Työpöytäasennus on tietysti eri asia. Oleellista on myös sammutetaanko tietokone käyttökertojen välillä vai laitetaanko se lepotilaan.

Xfs taisi olla se joka hajoaa levytilan täyttyessä (ei ilmoita mitenkään, tallentaa muistiin yli menevät tiedot) tai virran katketessa? Eli suunniteltu ihan eri ympäristöihin joissa virta ei katkea eikä levytila lopu

Kuinka tuoretta tietoa tämä on? Millä todennäköisyydellä tämä voi pitää paikkaansa vielä nykyään? Entä onko tuo tiedostojärjestelmän vai ainoastaan Linux-toteutuksen ominaisuus?

Jfs... no, se voisi olla mielenkiintoinen, tosin joissain benchmarkeissa ei ihan yhtä paljon ext3:ta arempi kuin xfs, ja olikohan senkin kanssa jotain perustavalaatuista ongelmaa...

FUDin sijasta olisi kiva kuulla faktoja.

Ext3:sta ja reiserfs:sta löytyy vaikka kuinka paljon nettilähteitä joissa niitä verrataan toisiinsa ja vuoronperään toinen on epäluotettava ja toinen vakaa kuin Kiinan muuri. Suurin osa niistä taitaa olla luotettavuudeltaan samaa luokkaa kuin tuo yllä oleva epäily.

Eli oma käsitykseni ainakin on, ettei vaihtoehtoja ext3:lle yksinkertaisesti ole, jos mietitään yleiseksi valinnaksi sopivia vaihtoehtoja.

Se määräaikaistarkistus vain on aikamoinen pommi.

Ext4 vaikuttaa vahvimmalta kandidaatilta ext3:n korvaajaksi, joten voi vain toivoa että se tulee olemaan kilpailukykyinen xfs:n, jfs:n ja reiserfs4:n kanssa...

Tämä aivan luonnollista jos lähdetään oletuksesta että ext3 on paras vaihtoehto oletukseksi tällä hetkellä.

niin ja zfs:n, jota ei ole Linuxille ja jota en ole benchmarkeissa kovin paljon nähnyt.

Ominaisuuslistaa lukiessa kuola vain valuu, mutta ei voi mitään kun se ei ole lisenssiltään yhteensopiva. Siitä on muuten FUSE-toteutus olemassa eli ZFS-levyjä pystyy tarvittaessa lukemaan ja kirjoittamaan.

[Risto H. Kurppa]

Mielenkiintoista keskustelua!

Tässä linkkejä aiheen sivusta:
http://brainstorm.ubuntu.com/idea/8357/ (extin hylkääminen)
http://brainstorm.ubuntu.com/idea/2147/ (jfs)
http://brainstorm.ubuntu.com/idea/328/ (extin tarkastus sammutettaessa)

http://brainstorm.ubuntu.com/idea/6325/ (graafinen disk check) - sanotaan että Hardyssa olisi toteutettu. Kubuntu-puolella ei ainakaan, liekö sitten Ubussa vain.. Ja tähän liittyen tuolla oli joskus idea että pitäisi olla keskeytettävissä/skipattavissa ja mielestäni siitäkin sanottiin että hardyyn tulee mutta en siitä sitten tiedä.

En tiedostojärjestelmistä hirviästi tiedä mutta ext:n ~ongelma on tosiaan tuo levyn tarkastus - tai lähinnä se, että se voi paukahtaa käyntiin juuri väärään aikaan. Itse ehdottaisin tähän esim. mahdollisuutta skipata se kolmella peräkkäisellä bootilla tms, tämän jälkeen käynnistyisi väkisin.

r

[Ville Pöntinen]

Todella, minustakin mielenkiintoinen ketju, jatkakaa toki! Ja varsinkin palvelinten tiedostojärjestelmiä koskevat linkit kiinnostavat. (Kotikoneessa en niin pidä niin tärkeänä.)