Ubuntu Suomen keskustelualueet
Muut alueet => Muut käyttöjärjestelmät ja Linux-jakelut => Aiheen aloitti: Ux64 - 12.05.08 - klo:16.35
-
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.
-
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 (?)...
-
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.
-
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.
-
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... ;D
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. ;D :)
-
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ä.
-
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.
-
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.
-
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.
-
Koittakaapa tuhota esim. yksi pikakuvake työpöydältä Vistassa... 10 sekunttia parhaimmillaan.. tai pahimmillaan ;)
-
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?
-
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?
-
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ä.
-
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.
-
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ä (http://www.debian-administration.org/articles/388) 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.
-
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.
-
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.
-
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.
-
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
-
Todella, minustakin mielenkiintoinen ketju, jatkakaa toki! Ja varsinkin palvelinten tiedostojärjestelmiä koskevat linkit kiinnostavat. (Kotikoneessa en niin pidä niin tärkeänä.)
-
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ä.
Juu kyllä sen voi skipata escillä. Siinä vielä sanotaan (ainakin jos on splash käytössä) siitä. En ole kokeillut vaan antanut aina mennä.
-
Kuitenkin se häviää selvästi...
Oletko nähnyt real-world-benchmarkkeja viime aikoina? Useimmat näkemäni liittyvät tiettyjen operaatioiden suorittamiseen, ei esim. "Gnomen käynnistymisaika", "Kansion siirtäminen toiselle osiolle" tms., vaikka on niitä vaikeampi vakioidakin.
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).
Siitä on jo vuosia aikaa. Määräaikaistarkistus on iso/huono juttu, mutta työpöytäkäyttäjille huomattavasti kiltimpi kuin koneen käynnistymisajan esim. tuplaantuminen. Hardyssä tosiaan oletuksena sen voi ohittaa, ja parempiakin keinoja kuten fsck:n suorittaminen sammutettaessa on.
Jos kone toimii esimerkiksi palvelimena niin reiserfs vaikuttaa selvästi paremmalta kuin ext3. Työpöytäasennus on tietysti eri asia.
Palvelimella näin voi olla. ReiserFS:n wikipedia-artikkelissa sanotaan mm. "Some directory operations (including unlink(2)) are not synchronous on ReiserFS, which can result in data corruption with applications relying heavily on file-based locks (such as mail transfer agents qmail[4] and Postfix[5]) if the machine halts before it has synchronized the disk.". Luulen että nämä ovat tuttuja monille ReiserFS-käyttäjille, ja ainakin minulle oli. Se reiserfsck:n --rebuild-tree on IMO paljon pelottavampi vekotin kuin ext3:n normi-fsck.
Edelleen sen (http://en.wikipedia.org/wiki/ReiserFS#Criticism) mukaan kyseinen rebuild voi korruptoida myös lisää. Käytin sitä kuitenkin korruptioiden sattuessa mukisematta, vaikka silloinkin ohjeissa luki että se on vaarallinen toimenpide - kuitenkin ainoa toimenpide joka toimii ongelmien tullessa kun kone on kaatunut tai sähköt katkenneet. Sitten kun siltä yhdeltä levyltäni oikeasti hävisi tietoja lopulta niin riitti reiserfs. Kyllä tuo korruption / tiedon häviämisen riski tuntuu todellisemmalta kuin ext3:n kanssa. Silti myös harmittaa ext3:n hitaampi toiminta tietyissä toiminnoissa.
(xfs)
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?
Lähin referenssi http://pthree.org/2008/04/23/xfs-vs-reiser/ ja Kees Cookin kommentti sekä jlduggerin myötäily power failure -korruptioiden suhteen. Siellä myös viitataan johonkin FAQ:iin jossa asia myönnetään (käytä UPSia..), mutta en nyt löydä sitä. Itse artikkelista löytyy myös tieto että XFS olisi huomattavasti hitaampi kuin ReiserFS. XFS:n Linux-porttauksen kehitys on ilmeisesti kysymysmerkki.
Benchmarkkeja muuten ext2/3/4, reiserfs, reiserfs 4, jfs, xfs, brtfs: http://tservice.net.ru/~s0mbre/old/?section=projects&item=fs_contest2
(jfs)
FUDin sijasta olisi kiva kuulla faktoja.
Jep, JFS on ehdottomasti tarkemman tutustumisen arvoinen, ja minulla on ainoastaan siis muistikuva että olen nähnyt senkin hyvin syin rökitetyn, mutta se muistikuva voi sekoittua XFS-muistikuviin joten tosiaan ei-fudia ei vielä tarjolla.
Lisäys: nyt muistin/löysin (http://linux.derkeiler.com/Mailing-Lists/Debian/2008-01/msg01789.html) että IBM on lopettanut JFS:n kehityksen, joten senkin kanssa on vähän sama juttu että onko kehittäjiä / ylläpitäjiä.
Se määräaikaistarkistus vain on aikamoinen pommi.
Jep, vaikkakin lievennettävissä.
Tämä aivan luonnollista jos lähdetään oletuksesta että ext3 on paras vaihtoehto oletukseksi tällä hetkellä.
Tämä on tosiaan oletus. Hyviä kommentteja on ollut myös joidenkin distroylläpitäjien kommentit, mutta niitä en juuri nyt löydä heti.
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
Katsotaan jos Sun joskus keksisi GPL:tä Solariksensa CDDL:n sijaan, tosin se olisi varmaan sitten v3.
_Jos_ XFS/JFS kehitys on jäissä, ext4:n lisäksi ReiserFS 4 ja ZFS olisivat mahdollisia, mutta eihän ReiserFS 4:nkaan aktiinen kehitystyö lupaavalta näytä, plus on äärimmäisen monimutkainen möhkäle.
-
Haastava aihe.
On 3 erilaista journalointitasoa ainakin ext3 tapauksessa. Turvallisin on ensin ja nopein nopein viimeiseksi.
http://en.wikipedia.org/wiki/Ext3
1. Journal
2. Ordered (oletus ubuntussa ext3 kanssa)
3. Writeback (xfs ja jfs käyttävät tätä)
Ext3 osion voi liittää vaikka data=writeback optiolla. Silloin voitetaan nopeutta, mutta virtakatkoksen sattuessa voi hävitä lähiaikoina muuttunutta dataa.
Ainakin joskus reiserfs oli oletuksilla pienille tiedostoille parempi kuin ext3. Tähänkin voidaan vaikuttaa.
mke2fs komennon -T option voi käyttää määrittämään osion käyttötarkoitusta.
blocksize inode_size ja inode_ratio ominaisuuksien avulla.
Pienillä tai suurilla tiedostoilla saattaa saada näillä optioilla eron, jonka huomaa. Tuskin kuitenkaan tuollaista huikeaa 160 kertaista.
Oma käyttöni on niin tavallista, että käytössä on ext3 oletusasetuksilla.
-
Tähän ketjuun sopiva lainaus tuoreesta Tietokone-lehdestä, kuvateksti s. 63
...Windows-maailman ulkopuolella on koko joukko nykyaikaisia järjestelmiä, kuten Linuxin ext3.
-
Lisää testituloksia Vista vs. Ubuntu!
;D
-
Kuitenkin se häviää selvästi...
Oletko nähnyt real-world-benchmarkkeja viime aikoina? Useimmat näkemäni liittyvät tiettyjen operaatioiden suorittamiseen, ei esim. "Gnomen käynnistymisaika", "Kansion siirtäminen toiselle osiolle" tms., vaikka on niitä vaikeampi vakioidakin.
Tuo linkkaamani taitaa olla tuorein näkemäni ja pärjäsihän ext3 siinäkin varsin kohtuullisesti muihin verrattuna. Suurimmat ongelmat olivat vain niillä osa-alueilla jotka ovat tärkeitä digitv-tallennuksia tehtäessä eli suurien tiedostojen käsittelyssä. Erityisesti tiedoston poistaminen on hidas operaatio.
Jos nyt kaksi suurinta ext3:n ongelmaa toteaisin niin ne ovat määräaikaistarkistukset ja suhde jolla levytilaa hyödynnetään. Näitä lukuunottamatta se on mielestäni ihan passeli yleiskäyttöinen tiedostojärjestelmä.
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).
Siitä on jo vuosia aikaa. Määräaikaistarkistus on iso/huono juttu, mutta työpöytäkäyttäjille huomattavasti kiltimpi kuin koneen käynnistymisajan esim. tuplaantuminen.
Enpä nyt sanoisi noinkaan jos keskimääräisestä liitosajasta sillä tulee suurempi. Tämän arvioimiseksi pitäisi olla jotain tietoa kauanko tuo oikeasti kestää isoilla levyillä.
Hardyssä tosiaan oletuksena sen voi ohittaa, ja parempiakin keinoja kuten fsck:n suorittaminen sammutettaessa on.
Kuinka monta kertaa sen voi ohittaa? Jos sen voi aina ohittaa niin sitä ei välttämättä suoriteta koskaan. Kuinka välttämätöntä sen suorittaminen ylipäätään on? Onko ext3 luonteeltaan jotenkin erilainen kuin muut tiedostojärjestelmät jotta tuolle määräaikaistarkistukselle on enemmän tarvetta vai tuoko se vain lisävarmuutta levyn hajoamisen havaitsemiseen?
Tuo tarkastuksen suorittaminen sammutettaessa kuulostaa minusta hyvältä ja sopii erityisesti desktop-käyttöön. Kannettavissa taas tarkistus ei sovi oikein mihinkään väliin.
Se reiserfsck:n --rebuild-tree on IMO paljon pelottavampi vekotin kuin ext3:n normi-fsck.
Juu, sitä ei parane ajaa ennen kuin kaikki kopioitavissa oleva data on siirretty parempaan talteen.
Edelleen sen (http://en.wikipedia.org/wiki/ReiserFS#Criticism) mukaan kyseinen rebuild voi korruptoida myös lisää.
Totta. Siksi sitä ei saakaan tehdä ennen kuin kaikki ehjä data on kopioitu talteen. Eri asia sitten jos osiota ei saa lainkaan liitettyä.
(xfs)
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?
Lähin referenssi http://pthree.org/2008/04/23/xfs-vs-reiser/ ja Kees Cookin kommentti sekä jlduggerin myötäily power failure -korruptioiden suhteen. Siellä myös viitataan johonkin FAQ:iin jossa asia myönnetään (käytä UPSia..), mutta en nyt löydä sitä.
Tämä oli hyvä tietää. Kiitoksia.
_Jos_ XFS/JFS kehitys on jäissä, ext4:n lisäksi ReiserFS 4 ja ZFS olisivat mahdollisia, mutta eihän ReiserFS 4:nkaan aktiinen kehitystyö lupaavalta näytä, plus on äärimmäisen monimutkainen möhkäle.
Tämän hetken tilanne on kieltämättä varsin synkkä. Tapahtuuko ext4:n yhteydessä jotakin tuolle määräaikaistarkistukselle? Ainakin Wikipedian perusteella minulle jäi käsitys että tarkistus olisi ainakin nopeampi.
-
Tuo kovalevyn tarkistus bootissa oli jossain Hardyn suunnitteluvaiheessa suunnitteilla siirtää sammutusvaiheeseen, mutta sysstä tai toisesta jaätettiin tuohon boottiin. Senhän verranhan bootissa on syytä tarkistaa, että on millä aloittaa käynnistys. ;D
Ketä asia kiusaa, voi etsiä ratkaisua. Löytyy palikka, joka siirtää tarkistuksen sammutusvaiheeseen. En nyt ehdi hakea sitä, mutta noin vinkiksi.
T:Jallu59
-
Onko fstabissa käytettävällä atime tai noatime parametrilla muuten paljon vaikutusta nopeuteen? En siis oikein ole ymmärtänyt miksi noatime ei ole oletuksena päällä jos sen käyttäminen pitäisi monien jenkkitopicien mukaan nopeuttaa levytoimintaa. Onko tällä eniten yhteyttä indeksointiin, vai?
Eee:llä siis suositellaan tuota noatimen käyttöä, että ssd kestäisi teoriassa pikkuisen pitempään kun kirjoituksia ei pitäisi tulla ihan niin paljon kiintolevylle. Kokeilin huvikseni ps3:lla missä on tuo n.200Mt muistia käytössä ja sehän luonnollisesti swappailee todella helposti + kiintoley mallia kannettava. Ei tullut testattua millään ohjelmalla onko eroa. Perstuntumalta ehkä ihan himpun verran, mutta ei mitään järkyttävää eroa kuitenkaan. Tosin samalla kikkailin vm.swappiness arvon kanssa.
Viisaammilta kommentteja? :)
-
AdvFS:n lähdekoodi julkaistiin GPL lisenssillä. Seuraava linkki on lähinnä ZFS:n ominaisuuksia kaipaaville.
http://en.wikipedia.org/wiki/AdvFS
Eee:llä siis suositellaan tuota noatimen käyttöä, että ssd kestäisi teoriassa pikkuisen pitempään kun kirjoituksia ei pitäisi tulla ihan niin paljon kiintolevylle.
Tiedoston lukeminen muuttaa sen atimea. Näin jokaisesta lukuoperaatiosta tulee myös kirjoitusoperaatio. Tarkennus kelpaa, mutta toivottavasti idea selviää.