Ubuntu Suomen keskustelualueet
Muut alueet => Yleistä keskustelua => Aiheen aloitti: Ked - 06.11.07 - klo:15.43
-
Noh, jokos jollakin on testikokemusta mokomasta ??? ..ja tukeeko Gutsyn kerneli uuttaa ext4:sta - version puolestahan se voisi olla mahdollista...
-
Mitä uusia ominaisuuksia siinä nelosessa on? Saako sen helposti käyttöön ja saako siitä jotain hyötyä (tietysti riippuu käyttö tarkoituksesta)?
-
http://linux.fi/index.php/Ext4
-
Ext4 on vielä kehitysvaiheessa. Eli siinä on toki uusia ominaisuuksia, mutta se voi olla hyvin epävakaa ja sisältää paljon vikoja. Tavalliselle käyttäjälle siitä ei liene suunnatonta hyötyä.
Huomioitavaa on, että jos sitä käyttää, pitää tosissaan varautua kaiken datan menetykseen. Pahimmillaan data voi tuhoutua korruptoitumalla, jolloin sitä ei välttämättä heti huomaa.
-
kätevää, vielä jos jaksaisi asentaa Wintoosaan tuen ext2/ext3/ext4 -osioille, voisi sanoa hellät hyvästit ulkoisen FAT32:hdelle, tai ainakin osioida sen puoliksi NTFS:äksi ja puoliksi ext:ksi, koska koulun koneisiin ei oikein kannata ext -tukea asennella, ja pitää välillä siirrellä isojakin tiedostoja/ kansioita.
-
kätevää, vielä jos jaksaisi asentaa Wintoosaan tuen ext2/ext3/ext4 -osioille, voisi sanoa hellät hyvästit ulkoisen FAT32:hdelle, tai ainakin osioida sen puoliksi NTFS:äksi ja puoliksi ext:ksi, koska koulun koneisiin ei oikein kannata ext -tukea asennella, ja pitää välillä siirrellä isojakin tiedostoja/ kansioita.
Tuoko ext4 tähän tilanteeseen jotain uutta? Ei mitenkään pahalla, mutta viestistä jäi jotenkin semmoinen kuva.
-
siis tarkoitin, että voisi alkaa käyttää kotona ext -alustettua ulkoista kiintolevyä linuxin ja Wintoosan välillä, ja jättää myös NTFS -osion samaiselle kiintolevylle koulutöitä varten. En siis ole asentanut ext -tukea Windowsiin, koska ei ole ollut tarvetta, nelosen myötä voisi sen asentaa.
-
siis tarkoitin, että voisi alkaa käyttää kotona ext -alustettua ulkoista kiintolevyä linuxin ja Wintoosan välillä, ja jättää myös NTFS -osion samaiselle kiintolevylle koulutöitä varten. En siis ole asentanut ext -tukea Windowsiin, koska ei ole ollut tarvetta, nelosen myötä voisi sen asentaa.
anteeks nyt pojjaat maalaisuuteni, mutt mitäs iloa luulet winukalle tuottavan tuon ext4:n asentamisella...?
luuleks, ett winkkari ja sen sovellukset osaa kirjoittaa tai lukee siltä? ...ext4 kun linuxin käyttämä tiedostojärjestelmä...
koska winkkariin on ext-tuki tehty?
-
siis tarkoitin, että voisi alkaa käyttää kotona ext -alustettua ulkoista kiintolevyä linuxin ja Wintoosan välillä, ja jättää myös NTFS -osion samaiselle kiintolevylle koulutöitä varten. En siis ole asentanut ext -tukea Windowsiin, koska ei ole ollut tarvetta, nelosen myötä voisi sen asentaa.
anteeks nyt pojjaat maalaisuuteni, mutt mitäs iloa luulet winukalle tuottavan tuon ext4:n asentamisella...?
luuleks, ett winkkari ja sen sovellukset osaa kirjoittaa tai lukee siltä? ...ext4 kun linuxin käyttämä tiedostojärjestelmä...
koska winkkariin on ext-tuki tehty?
Pienen ikuisuuden ajan on ext2 ja ext3 -osioita voitu lukea ja niille kirjoittaa Windowsista käsin, minun on siirreltävä materiaalia Winun ja Linukan välillä, mutta NTFS-3G:tä en ole saanut asennettua, koska paketit pitäisi ladata Synapticilla netistä, kotona ei ole nettiä, Wintoosaan on siis asennettava jotain, että saan sen ymmärtämään ext -osioita, ja tarvittaessa hakemaan näiltä osioilta tiedostoja ja lisäämään niitä sinne, ulkoisella kovolla on pakko olla FAT-32, että molemmista järjestelmistä voidaan kirjoittaa sille, jos saan ext -tuen asennettua, voin osioida kovosta suurimman osan ext:ksi ja loput NTFS:ksi koulukäyttöön, jatkuvat tiedostokoon rajoitukset, fragmentoituminen (pahempi kuin NTFS:llä) jne. alkavat ottaa pannuun ja kovaa.
EDIT: http://www.diskinternals.com/linux-reader/ tuolla
-
siis tarkoitin, että voisi alkaa käyttää kotona ext -alustettua ulkoista kiintolevyä linuxin ja Wintoosan välillä, ja jättää myös NTFS -osion samaiselle kiintolevylle koulutöitä varten. En siis ole asentanut ext -tukea Windowsiin, koska ei ole ollut tarvetta, nelosen myötä voisi sen asentaa.
anteeks nyt pojjaat maalaisuuteni, mutt mitäs iloa luulet winukalle tuottavan tuon ext4:n asentamisella...?
luuleks, ett winkkari ja sen sovellukset osaa kirjoittaa tai lukee siltä? ...ext4 kun linuxin käyttämä tiedostojärjestelmä...
koska winkkariin on ext-tuki tehty?
Pienen ikuisuuden ajan on ext2 ja ext3 -osioita voitu lukea ja niille kirjoittaa Windowsista käsin, minun on siirreltävä materiaalia Winun ja Linukan välillä, mutta NTFS-3G:tä en ole saanut asennettua, koska paketit pitäisi ladata Synapticilla netistä, kotona ei ole nettiä, Wintoosaan on siis asennettava jotain, että saan sen ymmärtämään ext -osioita, ja tarvittaessa hakemaan näiltä osioilta tiedostoja ja lisäämään niitä sinne, ulkoisella kovolla on pakko olla FAT-32, että molemmista järjestelmistä voidaan kirjoittaa sille, jos saan ext -tuen asennettua, voin osioida kovosta suurimman osan ext:ksi ja loput NTFS:ksi koulukäyttöön, jatkuvat tiedostokoon rajoitukset, fragmentoituminen (pahempi kuin NTFS:llä) jne. alkavat ottaa pannuun ja kovaa.
EDIT: http://www.diskinternals.com/linux-reader/ tuolla
Itse tässä kuitenin ihmettelen, mitä tässä ext4:ssä on niin hienoa, että se tuossa käytössä olisi oleellisesti ext3:a parempi. Ja kun ext3 on ollut jo käytössä ties miten kauan, niin mikset jo käytä sitä? Ext4 -tuen saaminen Windowsiin tulee todennäköisesti kestämään vielä aika pitkään, kun Linuxissakaan sitä ei käytetä kuin kokeilumielessä.
-
Ext4 -tuen saaminen Windowsiin tulee todennäköisesti kestämään vielä aika pitkään, kun Linuxissakaan sitä ei käytetä kuin kokeilumielessä.
Ei kestä. Tuolla ohjelmalla voi varmaankin mountata jo nyt ext4-osion Windowsiin, mutta ext4:n uudet ominaisuudet eivät ole käytössä. Ts. sen saa mountattua ext3 tai ext2 tilassa Windowsiin.
-
Luulisin, että ext2 tilassa, koska tietääkseni tuo ajuri käyttää ext3-levyäkin ext2:a.
-
EDIT: http://www.diskinternals.com/linux-reader/ tuolla
Hieman epäilen ettei tuo oikeasti tue ext3:sta vaan ainoastaan ext2:sta. Lisäksi se ei käsittääkseni mahdollista osion mounttaamista vaan tarjoaa oman tiedostoselaimen jolla osion tiedostoja voi käsitellä.
Itse todennäköisesti valitsisin ennemmin oikean tiedostojärjestelmäajurin jonka avulla osiot saa mountattua oikeasti: http://www.fs-driver.org/ (http://www.fs-driver.org/).
-
Jaa se on vielä testiversio. Surffaillessani törmäsin yhteen nopeustestiin jossa oli verrattu eri järjestelmien nopeuksia ja ext4 sai kohtalaisen hyvät arvosanat. Taidankin tyytyä toistaiseksi lukemaan testejä jos se saattaa kadottaa dataa...
voin osioida kovosta suurimman osan ext:ksi ja loput NTFS:ksi koulukäyttöön
Just tänään mietiskelin voiko ulkoisen kovalevyn ongelmitta osioida useampaan osaan. Kaiketi voi... mutta ilmeisesti se mounttaa sitten aika kivan kasan kuvakkeita työpöydälle kun iskee kiinni vaikka viiteen osaan osioidun levyn.. ja kaikki täytyy ilmeisesti irrottaa myös yksi kerrallaan ???
-
Tarkoitin, että voisi olla hyvä aika siirtyä käyttämään ext:tä, mutta kun nyt kerran nelosversio on tulossa, ei liene järkevää alkaa käyttää ohjelmaa, joka kuitenkin pitäisi korvata uudemmalla versiolla melko pian.
-
Kyllähän se Ext3 on varmasti erittäin hyvä vaihtoehto jatkossakin. Jotkut käyttävät vielä Ext2:akin. Esimerkiksi noille USB-muistitikuille Ext2 on kuulemma parempi vaihtoehto kuin Ext3 vähäisemmän kirjoituskuormansa vuoksi. Flash-muisti kun kuluu enimmäkseen sitä kirjoitettaessa, ei niinkään luettaessa.
Ext4:ssä ei nyt minusta mitään hirveän mullistavia juttuja ole tulossa, joten ei siihen varmastikaan pakko ole siirtyä heti ensimmäisen Linux-jakelun ottaessa sen oletuskena käyttöön tai jotain. Ext3 on siitäkin parempi vaihtoehto, että välillä saattaa tulla vastaan joku vanhempikin Linux-kone.
-
Kyllähän se Ext3 on varmasti erittäin hyvä vaihtoehto jatkossakin. Jotkut käyttävät vielä Ext2:akin. Esimerkiksi noille USB-muistitikuille Ext2 on kuulemma parempi vaihtoehto kuin Ext3 vähäisemmän kirjoituskuormansa vuoksi. Flash-muisti kun kuluu enimmäkseen sitä kirjoitettaessa, ei niinkään luettaessa.
Kyseessä oleva ulkoinen kovalevy on LaCien 250 gigainen "Porche", eli sisällä hyrrää oikea, 250Gt 8MB Cache 7200rpm -kiintolevy, joten kolmonen voisi tulla kyseeseen.
-
Kyllähän se Ext3 on varmasti erittäin hyvä vaihtoehto jatkossakin. Jotkut käyttävät vielä Ext2:akin. Esimerkiksi noille USB-muistitikuille Ext2 on kuulemma parempi vaihtoehto kuin Ext3 vähäisemmän kirjoituskuormansa vuoksi. Flash-muisti kun kuluu enimmäkseen sitä kirjoitettaessa, ei niinkään luettaessa.
Kyseessä oleva ulkoinen kovalevy on LaCien 250 gigainen "Porche", eli sisällä hyrrää oikea, 250Gt 8MB Cache 7200rpm -kiintolevy, joten kolmonen voisi tulla kyseeseen.
Itsellä muuten sama levy, mutta vaan 500GB mallina. Ensitöikseni jaoin levyn kahteen ext3 osioon, koska levy on vain linux koneiden käytössä (ja varmaan muutenkin olisin sen ext3:ksi laittanut).
-
Kyseessä oleva ulkoinen kovalevy on LaCien 250 gigainen "Porche",
Minulla on sama levy. Koska 250Gt vfat ei ole kovin järkevää, osioin levyn heti tarpeitani vastaavasti.
Vfat jäi myös levylle juuri siksi, että levy voidaan siirtää myös tarvittaessa jollekin Windows-koneelle.
Nimim. "Elän toistaiseksi MS Windows-vapaassa asunnossa"
-
Ext4 real word performance bench mark on nyt sitten julkaistu:
http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&num=1
Ihan hyvältä näyttää.
-
Ahaa... täytyy lukaista isommalla ajalla tuo artikkeli.
-
Noh, jokos jollakin on testikokemusta mokomasta ??? ..ja tukeeko Gutsyn kerneli uuttaa ext4:sta - version puolestahan se voisi olla mahdollista...
ext4 tulee kait vasta kohta julkaistavaa 2.6.28-kerneliin.
Sen päivittämistä ei sitt taas kaikkien kantsi yrittää jo vaikkapa näytönohjaimen ajurin 'jatkuvien' uus-asennusten vuoksi kernelipäivitysten seurauksena.
Mut jos osaat ja viitsit, niin siitä vaan. Meikäläinen odottaa kiltisti kevään cersuja
-
Minulla ollut ext4 käytössä kahdessa koneessa Fedora 9:stä lähtien ja toiminut moitteetta.
-
Niin, jos onnistuu seuraavat operaatiot:
ext3-->ext4
ext3-->btrfs
Toki toinen on valmis ja toinen sitä ei ole ::)
Niin kumpihan kannataisi jos ei pahemmin tarvetta sellaiselle koe, mutta silti haluasi päivittää joskus kaukaisessa tulevaisuudessa ;D?
Varsinkaan, kun en ole omia levyjäni en ole alustelemassa.
-
Niin kumpihan kannataisi jos ei pahemmin tarvetta sellaiselle koe, mutta silti haluasi päivittää joskus kaukaisessa tulevaisuudessa ;D?
Varsinkaan, kun en ole omia levyjäni en ole alustelemassa.
Ainoa Pro ext4ssa miksi minä sitä kaipaisin on tuo defrag mahdollisuus. Sekään ei ole ratkaisevan tärkeä, mutta pidän sitä merkittävänä puutteena nykyisessä ext3:ssa.
Tai siis toisaalta, eihän mikään estä defragin tekemistä ext3:lle, mutta mitä ilmeisimmin fiksuja sitä hoitavia softia ei ole ollut tyrkyllä. Jota olen kyllä suuresti ihmetellyt.
Ihan sama kuin jengi valittaa fatin toiminnasta, mikään ei estä tekemästä fat yhteensopivaa järjestelmää jossa on fiksumpi allokointi ratkaisu. Mikään ei pakota käyttämään klustereita alusta alkaen ensimmäisestä vapaasta lähtien. Mutta tämä nyt on tietenkin saivartalua, eikä liity sinänsä käytäntöön. Mutta jos ihan faktana asiaa käsitellään, niin olen kuitenkin oikeassa. ;) ext3 ei tarjoa mitään sellaista fragmentoitumisen estämismekanismia jota ei voitaisi aivan yhtähyvin käyttää fatin kanssa. Eikä sen puoleen ext4kään. ;) Esim blokki / extent tuki olisi todella helppoa toteuttaa fatinkin kanssa.
Sitten jotain muuta luettavaa tämän ketjun pohtijoille.
http://en.wikipedia.org/wiki/ExFAT
Riippuu myös paljon käytöstä mitä ominaisuuksia tarvitaan. mm. snapshotit (btrfs) koen täysin turhiksi.
Näitä ominaisuuksia taas voisin pitää rajallisesti kätevinä Object-level mirroring and striping, sekä online defragia. Varsinkin tuo Mirroring / striping objekti tasolla voi osoittautua käteväksi.
-
anteeks nyt pojjaat maalaisuuteni, mutt mitäs iloa luulet winukalle tuottavan tuon ext4:n asentamisella...?
luuleks, ett winkkari ja sen sovellukset osaa kirjoittaa tai lukee siltä? ...ext4 kun linuxin käyttämä tiedostojärjestelmä...
koska winkkariin on ext-tuki tehty?
Windows NT-käyttöjärjestelmässä ei ole Ext* tiedostojärjestelmän tukea. Sen kyllä saa jos asentaa erinäisen ohjelman joka osaa moista lukea. Ja ohjelmien itse ei tarvitse osata tiedostojärjestelmiä lukea/kirjoittaa vaan käyttöjärjestelmän (eli Windows NT, Linux ydin) huolehtii raudasta ja tarjoaa rajapinnat ohjelmille. Tällöin ohjelmien ei tarvitse osata käskyttää esimerkiksi kiintolevyn lukupäätä miten sitä siirretään, miten luetaan tietoa ja miten kirjoitetaan ynnä muita asioita. Ext4-tiedostojärjestelmään ei kannata vielä siirtyä, se on vähän nopeampi kuin Ext3 mutta kannattaa mielummin katsoa vaikka XFS- tai peräti ReiserFS-tiedostojärjestelmiä jos ei Ext3 kelpaa.
-
Ainoa Pro ext4ssa miksi minä sitä kaipaisin on tuo defrag mahdollisuus. Sekään ei ole ratkaisevan tärkeä, mutta pidän sitä merkittävänä puutteena nykyisessä ext3:ssa.
Tai siis toisaalta, eihän mikään estä defragin tekemistä ext3:lle, mutta mitä ilmeisimmin fiksuja sitä hoitavia softia ei ole ollut tyrkyllä. Jota olen kyllä suuresti ihmetellyt.
Linux-käyttöjärjestelmän osaavat yleiset tiedostojärjestelmät kuten Ext2 (Ext3 on Ext2 + journalointi) ei tarvitse eheyttämistä. Koska levy ei pirstaloidu hidastavasti kunhan kiintolevyllä on tilaa aina 15-20%. Kun tila vähenee tuosta niin silloin alkaa pirstaloitumistakin ilmestymään ja se voidaan korjata ihan vain kirjoitamalla data uusiksi (kopionti ym).
Linux-käyttöjärjestelmä on aina (ainakin 1.2.x versiosta lähtien) osannut kirjoittaa tiedostojärjestelmät älykkäästi kun tiedostojärjestelmien toimintaa on kehitetty. Kun Windowsissa tiedostot kirjoitetaan peräkanaan, tiedostot pirstaloituvat hyvinkin nopeasti. Mutta Linux-käyttöjärjestelmän tiedostojärjestelmillä tiedostot kirjoitetaan sinne missä on tilaa, aina pitäen vapaata tuleville tiedostoille ja tällöin pirstoutumista ei tapahdu. Ja koska sitä ei tapahdu, ei eheytystyökalujaan ole tarvittu. Kannattaa tutustua erilaisiin tiedostojärjestelmiin niin löytyykin tietoa miksi Linux-käyttöjärjestelmä on suosittu etenkin palvelin-tietokoneissa erilaisissa järjestelmissä missä vaaditaan luotettavuutta ja tiedostojen käytön suurta tehokkuutta.
-
Olikos tässä ketjussa jo esillä, että ext4:n fsck on merkittävästi ext3:n tsekkausta nopeampaa? Mikä on todella hyvä juttu nykyisten aina vain isompien levyjen aikana ja varmasti mukava parannus ajatellen vaikkapa ns. Ubuntun peruskäyttäjää, joka luottaa oletusarvoihin 30 (vai oliko se 25) liitoskerran jälkeisestä tarkistuksesta. Tuolla vähän kernel-kehittäjän mittaustuloksia asiasta:
http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ (http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/)
Itse olen ajatellut siirtyä Jauntyn myötä ext4:ään, jos se vain tulee julkaisun kerneliin mukaan.
-
Mutta Linux-käyttöjärjestelmän tiedostojärjestelmillä tiedostot kirjoitetaan sinne missä on tilaa, aina pitäen vapaata tuleville tiedostoille ja tällöin pirstoutumista ei tapahdu. Ja koska sitä ei tapahdu, ei eheytystyökalujaan ole tarvittu. Kannattaa tutustua erilaisiin tiedostojärjestelmiin niin löytyykin tietoa miksi Linux-käyttöjärjestelmä on suosittu etenkin palvelin-tietokoneissa erilaisissa järjestelmissä missä vaaditaan luotettavuutta ja tiedostojen käytön suurta tehokkuutta.
On tutustututtu ja juuri siksi tuota ext4:ta kaipaankin. Tuo esittämäsi malli oli sitä ihan samaa shaibaa mitä jauhetaan monessa sitessä, silloin kun ei ole faktaa käytettävissä. ext3:ssa ei ole mitään mikä estäisi fragmentoitumisen, eikä mitään mikä poistaisi sen kun sitä syntyy. Ajanmyötä tilanne siis todennäköisesti huononee. Mutta tämä ei ollut tämän keskustelun pääasiallinen aihe, koska tämä asia on jo käsitelty aikaisemmin.
fsck:n nopeutuminen on pelkkää plussaa. Melkoisesti menee aikaa kun tuon teratavun kapasiteetin chekkaa.
-
fsck:n nopeutuminen on pelkkää plussaa. Melkoisesti menee aikaa kun tuon teratavun kapasiteetin chekkaa.
Enpä tiedä. Asiat kyllä muuttuu parempaan, mutta kuinkapaljon ja millä hinnalla jää mielestäni auki.
Luin muitakin tarinoita asiasta, ja niiden perusteella sain käsityksen, että täys-määräisesti nämä parannukset koskee mahtavan kokoisia tiedostojärjestelmiä - sen kokoisia joiden kunniallinen fsck veisi vuosia. Nopeutus sadasta vuodesta yhteen ?
Toisaalta vihjattiin että ensisijaisesti tarkastettaisiinkin vain tiedostojen 'likainen bitti' ja jos se sanoo ettei dataa ole käytetty niin ei tiedostoa tarkistetakaan sen paremmin.
Tulee siis mieleen 'joidenkin' puhe että horroksesta herääminenhän on tavallaan boottaamista => "meidän käyttöjärjestelmä boottaa muutamassa sekunnissa - katso niin etköhän usko"
-
Luin muitakin tarinoita asiasta, ja niiden perusteella sain käsityksen, että täys-määräisesti nämä parannukset koskee mahtavan kokoisia tiedostojärjestelmiä - sen kokoisia joiden kunniallinen fsck veisi vuosia. Nopeutus sadasta vuodesta yhteen ?
Jos nopeutus on oikeasti satakertainen isoilla järjestelmillä on se varmasti ainakin kymmeniä prosentteja pienemmilläkin. Tai sitten tuossa oli joku algoritmi joka johti prosessin hidastumiseen esim potenssiin eikä lineaarisesti tms. En ole tutustunut tosin aiheeseen. Levytilat kasvavat edelleen huimaa vauhtia, joten itse en ainakaan pitstä tuota nopeutusta pahasta. Lähinnä tuo käynnistyksessä tapahtuva chekkaus ärsyttää silloin kun pistäisi koneen vain muutamaksi minuutiksi päälle esim tarkistaakseen mailit aamulla.
Toisaalta vihjattiin että ensisijaisesti tarkastettaisiinkin vain tiedostojen 'likainen bitti' ja jos se sanoo ettei dataa ole käytetty niin ei tiedostoa tarkistetakaan sen paremmin.
Tulee siis mieleen 'joidenkin' puhe että horroksesta herääminenhän on tavallaan boottaamista => "meidän käyttöjärjestelmä boottaa muutamassa sekunnissa - katso niin etköhän usko"
Niin, tiloja pitäisi olla mielestäni useita. Joku joka on täydellinen ja joku joka on tarpeenmukaan. Jos en ihan väärin ole ymmärtänyt, niin olettaen että journalointi toimii oikeasti, eikä laitteessa ole rautatason write cachea joka voi hukata dataa, niin fsck:lle EI pitäisi olla toimivalla raudalla syitä miksi se pitäisi suorittaa. Siitäkin huolimatta että järjestelmää "bootataan randomisti" vaikka reset napilla, pitäisi journalista pystyä päivittämään ainakin kirjanpito kuntoon transaktiotasolla. Jos dataa ei journaloida se voi korruptoitua, mutta se ei ole silloin kuitenkaan tämän järjestelmän vastuun piirissä.
Rehellisesti sanottuna on siis jäänyt ihmetyttämään tuo mihin tuota fsck:ta tarvitaan. Pyritäänkö sillä turvaamaan esim. rikkinäisestä hardiksesta johtuvia ongelmia? Vai myönnetäänkö suosiolla että journalointi on olemassa, mutta toimii puutteellisesti?
-
Lähinnä tuo käynnistyksessä tapahtuva chekkaus ärsyttää silloin kun pistäisi koneen vain muutamaksi minuutiksi päälle esim tarkistaakseen mailit aamulla.
Tuohon on helppo ja loistava ratkaisu: AutoFsck - tarkastaa levyt joko uudelleen käynnistyksessä tau sammutuksen yhteydessä (saa itse valittua)
Voi ladata täältä (https://wiki.ubuntu.com/AutoFsck)
-
Tuohon on helppo ja loistava ratkaisu: AutoFsck - tarkastaa levyt joko uudelleen käynnistyksessä tau sammutuksen yhteydessä (saa itse valittua)
Kyllä ja ei. Sammutuksessa tuleva viive on ihan yhtä ärsyttävä kuin käynnistyksessäkin. Silloin nimenomaan odottaa että saa homman valmiiksi ja pääsee siitä eroon. Normaalin käytön aikana koneesta on käytössä ehkä 3% ja resursseja tuollaisiin tehtäviin olisi vaikka kuinka. Mutta eipä toimi taustalla. ;(
-
Ai jaa, minä hyväksyn tarkistamisen ja sillä selvä. En jää koneen viereen odottelemaan. Ei ole koskaan stopannut vaan aina mennyt kiltisti läpi.
-
No nyt Torvalds sanoi tuon olevan vakaa.. jokos ootte konvertoinu levyjänne ext4 muotoon?
-
Mutta Linux-käyttöjärjestelmän tiedostojärjestelmillä tiedostot kirjoitetaan sinne missä on tilaa, aina pitäen vapaata tuleville tiedostoille ja tällöin pirstoutumista ei tapahdu. Ja koska sitä ei tapahdu, ei eheytystyökalujaan ole tarvittu. Kannattaa tutustua erilaisiin tiedostojärjestelmiin niin löytyykin tietoa miksi Linux-käyttöjärjestelmä on suosittu etenkin palvelin-tietokoneissa erilaisissa järjestelmissä missä vaaditaan luotettavuutta ja tiedostojen käytön suurta tehokkuutta.
On tutustututtu ja juuri siksi tuota ext4:ta kaipaankin. Tuo esittämäsi malli oli sitä ihan samaa shaibaa mitä jauhetaan monessa sitessä, silloin kun ei ole faktaa käytettävissä. ext3:ssa ei ole mitään mikä estäisi fragmentoitumisen, eikä mitään mikä poistaisi sen kun sitä syntyy. Ajanmyötä tilanne siis todennäköisesti huononee. Mutta tämä ei ollut tämän keskustelun pääasiallinen aihe, koska tämä asia on jo käsitelty aikaisemmin.
fsck:n nopeutuminen on pelkkää plussaa. Melkoisesti menee aikaa kun tuon teratavun kapasiteetin chekkaa.
niin kuin Fe13 kirjoitti tai toivoakseni tarkoitti, vaikka prosenttilukuja mainitsikin, että niin kauan kuin ext3:ssa tiedostot mahtuvat kokonaisina vapaaseen/vaipaisiin tiloihin, ei fragmentoitumista tapahdu. Mutta kun levytila on niin täynnä, että yhtenäistä tiedoston vaatimaa tilaa (lopusta tai välistä) löydy, niin silloinhan tiedosto pitää jakaa osiin eli se pätkittyy ...fragmentoituu. Mutt siis vasta kun levytila on täyttynyt liiaksi. Se usein mainittu 15% on toki jonkun arviointi.
Tää siis toisin, kuin fatit, jotka kirjoittaa ekaan vapaaseen pätkään sen mikä siihen mahtuu ja loput seuraavaan/seuraaviin vapaisiin tiloihin (aukkoihin)...
-
niin kuin Fe13 kirjoitti tai toivoakseni tarkoitti, vaikka prosenttilukuja mainitsikin, että niin kauan kuin ext3:ssa tiedostot mahtuvat kokonaisina vapaaseen/vaipaisiin tiloihin, ei fragmentoitumista tapahdu.
Nyt taisi mennä pieleen. Järjestelmä ei kasaa tiedostoja kasaan kun vapaa yhtenäinen tila loppuu, vaikka toisaalla olisikin tuolle tiedostolle tarpeeksi vapaata tilaa. Eli fragmentoitumista tapahtuu varsin nopeasti. Ext3:ssa ei myöskään ollut muistaakseni kunnollista pre-alloccia tai ainakaan sovellukset eivät sitä käytä. Koska pre-alloccia ei tehdä, mikä tahansa yhtä clusteria suurempi tiedosto voi fragmentoitua vaikka levyllä olisi kuinka paljon tilaa. 15% on siis puhdas heitto. Koska vapaa tila ei valitettavasti estä jo levylle allokoitujen tiedostojen fragmentoitumista mm. niiden kasvaessa. Olenkin esittänyt tästä aivan loistavan esimerkin tuotantopalvelimen kanssa jossa ongelma on suuren suuri, vaikka levytilaa on vapaana reilusti.
Tuo file pre-allocin puuttuminen muuten näkyy ainakin Vista koneissa todella nopeasti pahana fragmentoitumisena.
Tästä asiasta on jauhettu paljon. ;)
Lyhyestisanottuna ext3:ssa ei ole mitään mikä estäisi fragmentoitumisen tai poistaisi sen kun sitä syntyy. -> Ennemmin tai myöhemmin fragmentoituminen muodostuu ongelmaksi.
Btw. Esim IBM36 koneet oli siitä mainioita, että niiden käyttöjärjestelmä ESTI fragmentoitumisen, niissä siis ei ollut fragmentoitumis ongelmaa.
-
Nyt taisi mennä pieleen. Järjestelmä ei kasaa tiedostoja kasaan kun vapaa yhtenäinen tila loppuu, vaikka toisaalla olisikin tuolle tiedostolle tarpeeksi vapaata tilaa. Eli fragmentoitumista tapahtuu varsin nopeasti.
Jos tiedostot kasataan yhteen niin silloinhan mikään tiedosto ei enää pysty kasvamaan luontaisesti. Eikö tällä tavoin käytännössä varmisteta että vanhat tiedostot fragmentoituvat jatkossa takuuvarmasti?
Ext3 pyrkii normaalisti sijoittamaan hakemistohierarkiassa toisiinsa liittyvät tiedostot lähelle toisiaan. Kaikkien tiedostojen kasaaminen läjään ja yhtenäisen tilan vapauttaminen voi näin ollen jopa heikentää suorituskykyä.
Ext3:ssa ei myöskään ollut muistaakseni kunnollista pre-alloccia tai ainakaan sovellukset eivät sitä käytä.
Uskottavuuden kannalta olisi parempi jos ensiksi selvittäisit kummasta tapauksesta on kyse. Turha valittaa pre-allokoinnin puuttumisesta jos se on olemassa mutta ohjelmat eivät sitä käytä.
Ei sen puoleen. Äkkiseltään ei tule mieleen kovinkaan montaa käyttötarkoitusta jossa tuosta olisi suunnattomasti hyötyä. Kotikäytössä tuosta lienee hyötyä lähinnä vertaisverkko-ohjelmien yhteydessä sekä suuria tiedostoja ladattaessa.
Koska pre-alloccia ei tehdä, mikä tahansa yhtä clusteria suurempi tiedosto voi fragmentoitua vaikka levyllä olisi kuinka paljon tilaa.
Jos koko tila kuitenkin varataan kerralla niin fragmentoitumisen todennäköisyys ei ole kovin suuri. Lisäksi ryhmittelyn ansiosta ext3 pyrkii joka tapauksessa pitämään tiedot lähellä toisiaan mikäli se on mahdollista. Tämä voi tietyissä tilanteissa myös lisätä fragmentoitumista mutta tässäkään tapauksessa tiedot eivät ole fragmentoituneet levyn vastakkaisille laidoille vaan lähelle toisiaan.
Olenkin esittänyt tästä aivan loistavan esimerkin tuotantopalvelimen kanssa jossa ongelma on suuren suuri, vaikka levytilaa on vapaana reilusti.
En muista tarkkaan aiemmin kertomasi ongelman kuvausta mutta uskoisin ettei kaipaamastasi pre-allokoinnista olisi mitään hyötyä sen ratkaisussa.
Tuo file pre-allocin puuttuminen muuten näkyy ainakin Vista koneissa todella nopeasti pahana fragmentoitumisena.
Sekö on yksittäisenä tekijänä kaikkein merkittävin Vista-koneiden fragmentoitumisen aiheuttaja? Onko Vista-koneissa paljon (hitaasti luotavia) suuria tiedostoja joiden lopullinen koko tiedetään etukäteen?
Lyhyestisanottuna ext3:ssa ei ole mitään mikä estäisi fragmentoitumisen tai poistaisi sen kun sitä syntyy. -> Ennemmin tai myöhemmin fragmentoituminen muodostuu ongelmaksi.
Ja FAT olisi ihan yhtä hyvä jos joku vain kirjoittaisi sille kunnollisen allokaattorin... On tämä kuultu ennenkin.
Btw. Esim IBM36 koneet oli siitä mainioita, että niiden käyttöjärjestelmä ESTI fragmentoitumisen, niissä siis ei ollut fragmentoitumis ongelmaa.
Voisin arvata että tuollaisesta seuraa huomattavia suorituskykyongelmia suuria tiedostoja kirjoitettaessa.
-
niin kuin Fe13 kirjoitti tai toivoakseni tarkoitti, vaikka prosenttilukuja mainitsikin, että niin kauan kuin ext3:ssa tiedostot mahtuvat kokonaisina vapaaseen/vaipaisiin tiloihin, ei fragmentoitumista tapahdu.
Nyt taisi mennä pieleen. Järjestelmä ei kasaa tiedostoja kasaan kun vapaa yhtenäinen tila loppuu, vaikka toisaalla olisikin tuolle tiedostolle tarpeeksi vapaata tilaa. Eli fragmentoitumista tapahtuu varsin nopeasti. Ext3:ssa ei myöskään ollut muistaakseni kunnollista pre-alloccia tai ainakaan sovellukset eivät sitä käytä. Koska pre-alloccia ei tehdä, mikä tahansa yhtä clusteria suurempi tiedosto voi fragmentoitua vaikka levyllä olisi kuinka paljon tilaa. 15% on siis puhdas heitto. Koska vapaa tila ei valitettavasti estä jo levylle allokoitujen tiedostojen fragmentoitumista mm. niiden kasvaessa. Olenkin esittänyt tästä aivan loistavan esimerkin tuotantopalvelimen kanssa jossa ongelma on suuren suuri, vaikka levytilaa on vapaana reilusti.
Tuo file pre-allocin puuttuminen muuten näkyy ainakin Vista koneissa todella nopeasti pahana fragmentoitumisena.
Tästä asiasta on jauhettu paljon. ;)
Lyhyestisanottuna ext3:ssa ei ole mitään mikä estäisi fragmentoitumisen tai poistaisi sen kun sitä syntyy. -> Ennemmin tai myöhemmin fragmentoituminen muodostuu ongelmaksi.
Btw. Esim IBM36 koneet oli siitä mainioita, että niiden käyttöjärjestelmä ESTI fragmentoitumisen, niissä siis ei ollut fragmentoitumis ongelmaa.
Eipä tainnut mennä - enkä ole kasautumisen puolesta mitään maininnut edes.
Mutt ootko kuullu sellasesta - oliks se nyt hidas kirjoittaminen vai hidas tallentaminen? Sellanen oli käytössä jo aikoinaan OS/2:ssa.
Eli tiedot kirjoitettiin 'oikeasti' vasta hiukka myöhemmin, kun prosulle sallittiin hiukka 'läähätysaikaa'. Eli tieto säilytettiin välimuistissa ja tallennettiin vasta ko operaation päätyttyä. Sen koko oli siis silloin tiedossa ja se kirjoitettiin nimenomaan paikkaan, johon se mahtui kokonaisena, mikäli levyllä oli siihen tilaa.
Vain, jos yhtenäistä tilaa ei oo riittävästi tallennus joudittiin/joudutaan pilkkomaan osiin. Sitä kutsutaan pirstaloitumiseksi/sirpaloitumiseksi eli fragmentoitumiseksi... ja se on fatin tapa alusta alkaen tallennuksissa. Se tallentaa heti ekaan löytämäänsä paikkaan sen mikä siihen mahtuu ja loput seuraaviin tyhjiin paikkoihin. Ja näitä tyhjiä paikkoja syntyy, kun tiedostoja/sovelluksia poistetaan (deletoidaan) levyltä.
-
Jos tiedostot kasataan yhteen niin silloinhan mikään tiedosto ei enää pysty kasvamaan luontaisesti.
Eikö tällä tavoin käytännössä varmisteta että vanhat tiedostot fragmentoituvat jatkossa takuuvarmasti?
Tämä on myös yksi ikuisuuskysymyksistä ja optimointi pitäisi tehdä tiedostokohtaisesti kuten se joissain järjestelmissä tehtiinkin. Eli jokaiselle tiedostolle tulee laskea kasvuindeksi ja varata sen mukaan tarvittava tila jatkossa. Tämä auttaa siis nimenomaisesti hitaasti kasvaviin tiedostoihin. Jos tätä kasaamista ei tehdä, tulee ongelmaksi vapaantilan fragmentoituminen, jolloin kaikki tiedostot voi olla yhtenäisiä, mutta kun koitat tallentaa levylle gigan tiedoston, se ei mahdukkaan mihinkään vapaaseen paikkaan yhtenäisenä.
Ext3 pyrkii normaalisti sijoittamaan hakemistohierarkiassa toisiinsa liittyvät tiedostot lähelle toisiaan. Kaikkien tiedostojen kasaaminen läjään ja yhtenäisen tilan vapauttaminen voi näin ollen jopa heikentää suorituskykyä.
Tämä on erinomainen asia, siis tiedostojen sijoittaminen lähelle. Mikäli tiedostojen kasaamista yhtenäisiksi ei tehdä, niin silloinhan levy on jo fragmentoitunut.
Uskottavuuden kannalta olisi parempi jos ensiksi selvittäisit kummasta tapauksesta on kyse. Turha valittaa pre-allokoinnin puuttumisesta jos se on olemassa mutta ohjelmat eivät sitä käytä.
Toki, mutta en mä onneksi mitään väitöskirjaa tässä ole tekemässä. Kunhan horisen aikanikuluksi. Mutta kun pottuilit asiasta niin tarkistin, Wikipediasta katsottuna pre-allokointi puuttuu ext3:sta ja se on lisätty ext4:n. NTFS:ssä pre-alloc optio on olemassa. Mutta monet sovellukset jotka eivät ole alunperäin tehty Windowssille ja optimoitu em. asiaa silmälläpitäen eivät sitä kuitenkaan käytä. Tämä tarkoittaa sitä että jos ext3 levylle kirjoitetaan tiedosto joka voisikin mahtua pre-allocin kanssa vapaaseen levytilaan. Niin nyt tiedostoa ei osata aloittaa oikeasta kohdasta jotta se mahtuisi siihen tilaan, koska tiedoston lopullinen koko ei ole käytettävissä. Tämä on ollut varsinkin yksi tärkeimmistä pointeista miksei allokointi VOI toimia erityisen tehokkaasti ilman pre-allocin käyttöä. Silloin tiedon tallennus joudutaan aloittamaan johonkin ja jossain vaiheessa tulee (mahdollisesti) jotain muuta vastan ja fragmentoituminen alkaa. Vaikka olisi ollut mahdollista laittaa tiedosto vapaaseen tilaan, jos tiedoston lopullinen koko olisi ollut tiedossa. Tämä on siis yksi niitä tärkeimpiä pointteja, jotka mielestäni vesittää ext3:n "täydellisyyttä". Muitakin varmasti on, mutta en ole niihin perehtynyt.
Ei sen puoleen. Äkkiseltään ei tule mieleen kovinkaan montaa käyttötarkoitusta jossa tuosta olisi suunnattomasti hyötyä. Kotikäytössä tuosta lienee hyötyä lähinnä vertaisverkko-ohjelmien yhteydessä sekä suuria tiedostoja ladattaessa.
Eikö? Mielestäni siitä on aina ratkaisevaa hyötyä kun kirjoitettavaksi tulevan tietomäärän koko on ennakkoon tiedossa. Tämä siis koskee käytännössä kaikkia paitsi juuri noita ensimmäisessä osiossa mainittuja jatkuvasti kasvavia tiedostoja.
Jos koko tila kuitenkin varataan kerralla niin fragmentoitumisen todennäköisyys ei ole kovin suuri. Lisäksi ryhmittelyn ansiosta ext3 pyrkii joka tapauksessa pitämään tiedot lähellä toisiaan mikäli se on mahdollista. Tämä voi tietyissä tilanteissa myös lisätä fragmentoitumista mutta tässäkään tapauksessa tiedot eivät ole fragmentoituneet levyn vastakkaisille laidoille vaan lähelle toisiaan.
Jos pre-alloccia ei tehdä, niin tilaakaan ei voida myös varata kerralla. Tuohan on juuri pre-allocin ratkaisevin hyöty. Voidaan kertoa järjestelmälle että halutaan varata 1 gigatavu yhtenäistä tilaa. Eikä vain varata toistuvasti blokkeja kunnes tuo gigatavu on täynnä. Tämä tarkoitta siis tiedoston ennakkoon allokointia, eikä sen kasvattamista sitä mukaan kun tietoa valuu levylle.
Tämä ongelma tulee tuskallisen selvästi ilmi NTFS:llä ja esim 7-zip sovelluksella joka mitä ilmeisimmin ei käytä pre-alloccia. Kun pakkaan 4 gigan paketin, on se hajonnut helposti hajonnut levylle tuhansiin epäyhtenäisiin paloihin. Kun sitten otan tuon 7-zipin paketin. Kopioin sen ja tuhoan sen, on se todennäköisesti 1-2 palassa. Ei mitään hyötyä? Se on suhteellinen näkemys se. Tosiasiahan on se, että yksikään kone joissa on käytetty vaikka dossia kymmenen vuotta ja defragia ei ole tehty koskaan, ei ole siihen hajonnut.
En muista tarkkaan aiemmin kertomasi ongelman kuvausta mutta uskoisin ettei kaipaamastasi pre-allokoinnista olisi mitään hyötyä sen ratkaisussa.
Juuri kyseisessä esimerkissä siitä ei olisi mitään hyötyä. Siinä esimerkissä käytiin lähinnä läpi kasvavien tiedostojen ongelmaa. Eli allokoin levystä esimerkiksi 30% klusterin kokoisilla tiedostoilla. Sen jälkeen luen em. tiedot tietokantaan joka siis varaa nyt 30% varastusta levystä 30% yhtenäisellä tiedostolla joka kasvaa pikkuhiljaa. Jos nuo klusterin kokoiset tiedostot sijoitetaan hajalleen levylle, se johtaa myös tuon tietokannan fragmentoitumiseen. Tiedän, että tähän esimerkkiin ei ole helppoa järkevää ratkaisua. Tämä kuvaa juuri ongelmaan liittyvää kaksiteräisyyttä. Periaatteessa puhtaalla first fit ratkaisulla ei olisi ongelmaa. (jos unohdetaan se tosiasia että tiedostoja tulee niin paljon, että hakemisto klusterit leviävät kuitenkin tuonne tiedostojen väliin) Oikeastaan nuo tiedostot pitäisi ensin luoda nollatavuisina ja sen jälkeen lisätä vasta sisältö. ;)
Sekö on yksittäisenä tekijänä kaikkein merkittävin Vista-koneiden fragmentoitumisen aiheuttaja? Onko Vista-koneissa paljon (hitaasti luotavia) suuria tiedostoja joiden lopullinen koko tiedetään etukäteen?
Ei. Mutta juuri suurien 7-zip pakettien kanssa olen kiinnittänyt ongelmaan erityisesti huomiota, koska ainakin omassa työasemassani tuo on suurin fragmentoitumisen aiheuttaja. Sekä pakatessa, että purettaessa 7-zip siis ei varaa levytilaa tiedostoille yhtenäisinä paloina.
Lyhyestisanottuna ext3:ssa ei ole mitään mikä estäisi fragmentoitumisen tai poistaisi sen kun sitä syntyy. -> Ennemmin tai myöhemmin fragmentoituminen muodostuu ongelmaksi.
Ja FAT olisi ihan yhtä hyvä jos joku vain kirjoittaisi sille kunnollisen allokaattorin... On tämä kuultu ennenkin.
Kyllä! Olen kanssasi täsmälleen samaa mieltä kanssasi. Mainittakoon että käsittääkseni FAT-levyn allokointia ei ole täsmälleen määritelty. Joten allokoinnin suorittaminen on jokaisen itsenäisen implementaation asia. Se ei ole FATin vika jos sinä käytät tyhmää allokointimenetelmää. ;) FAT ei hajoa siitä, että sen kanssa käytetään sovellusta joka tukisi pre-alloccia, viivästettyä allokointia jne tehostavia toimenpiteitä.
Esim IBM36 koneet oli siitä mainioita, että niiden käyttöjärjestelmä ESTI fragmentoitumisen, niissä siis ei ollut fragmentoitumis ongelmaa.
Voisin arvata että tuollaisesta seuraa huomattavia suorituskykyongelmia suuria tiedostoja kirjoitettaessa.
Seurasi vielä suurempia ongelmia. Prosessit kaatuivat mikäli tiedostoille ennakkoon varattu kasvamistila loppui kesken. ;)
Seuraavaan viestiin konsolidoituna.
Mutt ootko kuullu sellasesta - oliks se nyt hidas kirjoittaminen vai hidas tallentaminen? Sellanen oli käytössä jo aikoinaan OS/2:ssa.
Muistaakseni oli ext4:n listalla myös tuo. Kasvaneet muistimäärät helpottaa ongelmaa, toisaalta taas levyjärjestelmän luotettavuus (powerloss) tilanteissa voi laskea olennaisesti ellei ole data journalointi käynnissä, joka taas laskee suorituskykyä.
Eli tiedot kirjoitettiin 'oikeasti' vasta hiukka myöhemmin, kun prosulle sallittiin hiukka 'läähätysaikaa'. Eli tieto säilytettiin välimuistissa ja tallennettiin vasta ko operaation päätyttyä. Sen koko oli siis silloin tiedossa ja se kirjoitettiin nimenomaan paikkaan, johon se mahtui kokonaisena, mikäli levyllä oli siihen tilaa.
Se on hyvä ratkaisu. Joskin ongelma muodostuu luonnollisesti hyvin suurien tiedostojen yhteydessä. Sekä jatkettaessa vanhoja, ellei käytetä niiden pienten kanssa copy on writeä. Toisaalta samaan tulokseen päästäisiin sillä, että tiedosto varattaisiin ennakkoon oikealle koolle. Mutta kuten sanottu, kaikki sovellukset eivät silti hyödynnä em. ominaisuutta. Tästä nämä ongelmat tulee usein, kun järjestelmä, joka toimii ei ole rikki. Nykyinen työnantajani ainakin vastustaa kaikkia parannuksia ja optimointeja henkeen ja vereen, mikäli ne eivät ole jonkun fataalin ongelman korjauksia. if It ain't broke, don't fix it. Fat journaloinilla olisi siis meillekkin optimi tiedostojärjestelmä. Selviäisi kaatumisista, eikä olisi turhan monimutkainen.
Ja näitä tyhjiä paikkoja syntyy, kun tiedostoja/sovelluksia poistetaan (deletoidaan) levyltä.
Vapaantilan fragmentoituminen koskee kyllä kaikkia muitakin järjestelmiä, joissa ei käytetä defragia. Eikä silloinkaan ole usein järkevää pakata kaikkea dataa yhteen kuten tässäkin ketjussa on todettu.
Ext4 korjaa mielestäni ainakin ne ongelmat jotka olivat ext3:n suurimpia puutteita. Lisäksi voitaisiin esittää kysymys, miksi Ext4 olisi ylipäätänsä tekeillä jos ext3:n kanssa ei mielletä olevan mitään parantamisen varaa. Ext3 ei mielestäni ollut niin täydellinen kuin linux fanaatikot aina haluavat uskoa tai sanoa sen olevan. Vielä useinmiten ilman minkäänlaista asiaan perehtymistä.
Mutta eiköhän tässä ollut jeesustelua taas kerrakseen. Lienee turhaa jatkaa tästä asiasta. - Kiitos
P.S. Esimerkiksi Deluge (Torrent Client) tekee ladattaville tiedostoille Full Allocationin, eli vaaraa koko tiedoston kerralla. Mutta kyse oli juuri siitä miten tuo varaaminen tapahtuu järjestelmän sisällä matallala tasolla. Pystyihän sitä FAT aikanakin esim Turbo Pascalilla helposti tekemään kerralla ison tiedoston. Siten että avaa sen kirjoitustilaan, heittää seekin esim. 10 megan kohdalle ja sulkee tiedoston. Lopputuloksena oli 10 megan tyhjä tiedosto. Se että varattiinko tuo 10 megaa blokki kerrallaan toistuvina varauksina vai osattiinko varata koko 10 megaa yhtenä palana on sitten ihan toinen kysymys. Ohjelmoijan kannalta lopputulos oli täysin sama. Tämä siis kuvastaa juuri sitä ongelmaan mitä manasin 7-zipin osalta, se ei varaa kerralla edes niitä tiedostoja joiden koko olisi tiedossa (purettaessa). Riippuen rajapinnosita ja järjestelmä logiikasta se miten levytila varataan käytännössä voi sitten olla täysin sama tai erilainen.
Edit täydennys: ext3:n preallokointi on saatavissa patchina. En kyllä tarkistanut asiaa tarkemmin, mutta näin google hakujen perusteella about 5 lähteestä.
-
en nyt oikein tiedä, mistä sä noita väittämiäsi ja niiden perusteluja revit, kuten 'kaikki sovellukset eivät osaa sitä (laiskaa tallennusta) käyttää'...
Eihän sovellukset mitään tallenna eivätkä edes tiedä mihin niiden tallennettavaksi pyytämät tiedostot käyttis tallentaa.
Sovellukset kyllä "tietävät" eli luulevat tietävänsä, kun ne 'tietävät' ko tiedoston tallennuspaikan, mutt käyttishän sen kuitenkin laittaa ihan oman päänsä mukaan ja pitää siksi ns "paikanhaku-taulukkoa" muistissaan ...se on, että se (käyttis) tietää missä sovelluksen jostain paikasta pyytämä tieto todellisuudessa majaileekaan...
Joten mitäs jos kyselisit tai lukisit enempi ja väittäisit vähempi näistä tallennus- ja fragmentaumisjutskista.
Sinänsä asia on jopa merkityksellinen, niin kuin nykyiset lukupäättömät tallennusmediat on osittaneet. Ne kun lienevät jo nopeampia kuin perinteiset levyt, jotka joutuvat siirtelemään lukupäitään tiedon pirstaleita noutaessaan umpitäysiltä levyiltä, joita joku höyrypää haluaisi vielä fatilla hidastaa... ;)
-
Mutta monet sovellukset jotka eivät ole alunperäin tehty Windowssille ja optimoitu em. asiaa silmälläpitäen eivät sitä kuitenkaan käytä. [...] Tämä on siis yksi niitä tärkeimpiä pointteja, jotka mielestäni vesittää ext3:n "täydellisyyttä".
Onko ext4 sitten täydellisempi kun se tukee tuota vaikkeivat sovellukset edelleenkään tue sitä. Sovelluksen kannaltahan tuo ei suurta muutosta vaadi mutta siitä huolimatta epäilen että määrällisesti harvat sovellukset tuota tulevat tukemaan lähiaikoina.
Ei sen puoleen. Äkkiseltään ei tule mieleen kovinkaan montaa käyttötarkoitusta jossa tuosta olisi suunnattomasti hyötyä. Kotikäytössä tuosta lienee hyötyä lähinnä vertaisverkko-ohjelmien yhteydessä sekä suuria tiedostoja ladattaessa.
Eikö? Mielestäni siitä on aina ratkaisevaa hyötyä kun kirjoitettavaksi tulevan tietomäärän koko on ennakkoon tiedossa. Tämä siis koskee käytännössä kaikkia paitsi juuri noita ensimmäisessä osiossa mainittuja jatkuvasti kasvavia tiedostoja.
Kyllä siitä hyötyä on mutta sen merkittävyydestä voidaan olla montaa mieltä. Pienille tiedostoille löytynee muutenkin melko helposti yhtenäistä tilaa.
Jos koko tila kuitenkin varataan kerralla niin fragmentoitumisen todennäköisyys ei ole kovin suuri. Lisäksi ryhmittelyn ansiosta ext3 pyrkii joka tapauksessa pitämään tiedot lähellä toisiaan mikäli se on mahdollista. Tämä voi tietyissä tilanteissa myös lisätä fragmentoitumista mutta tässäkään tapauksessa tiedot eivät ole fragmentoituneet levyn vastakkaisille laidoille vaan lähelle toisiaan.
Jos pre-alloccia ei tehdä, niin tilaakaan ei voida myös varata kerralla.
Viestin lopussa itsekin kuvasit miten tämä tapahtuu joten kyllä se tila voidaan varata kerralla. Tiedostojärjestelmän tasolla se tapahtuu kuitenkin sarjana yksittäisiä lohkojen varaamisia. Koska ne tapahtuvat kerralla peräkkäin niin todennäköisesti ne muodostavat lähes fragmentoitumattoman alueen.
Tämä ongelma tulee tuskallisen selvästi ilmi NTFS:llä ja esim 7-zip sovelluksella joka mitä ilmeisimmin ei käytä pre-alloccia. Kun pakkaan 4 gigan paketin, on se hajonnut helposti hajonnut levylle tuhansiin epäyhtenäisiin paloihin.
Pakatessa ei tiedetä lopullista kokoa. Purkamisessa tuo olisi tietysti mahdollista.
Tässä ei kuitenkaan enää ole kysymys ext3:n fragmentoitumisongelmista vaan ntfs:n fragmentoitumisesta. Et voi yleistää ntfs:n kanssa tekemiäsi kokeiluja koskemaan ext3:sta.
Kun sitten otan tuon 7-zipin paketin. Kopioin sen ja tuhoan sen, on se todennäköisesti 1-2 palassa. Ei mitään hyötyä? Se on suhteellinen näkemys se.
Miten tuo osoittaa että ext3 hyötyisi pre-allokoinnista?
Sekö on yksittäisenä tekijänä kaikkein merkittävin Vista-koneiden fragmentoitumisen aiheuttaja? Onko Vista-koneissa paljon (hitaasti luotavia) suuria tiedostoja joiden lopullinen koko tiedetään etukäteen?
Ei. Mutta juuri suurien 7-zip pakettien kanssa olen kiinnittänyt ongelmaan erityisesti huomiota, koska ainakin omassa työasemassani tuo on suurin fragmentoitumisen aiheuttaja. Sekä pakatessa, että purettaessa 7-zip siis ei varaa levytilaa tiedostoille yhtenäisinä paloina.
Ongelma ei siis liittynyt suoranaisesti Vista-koneisiin vaan pikemminkin ntfs:n ja 7zip:n keskinäiseen toimintaan käsiteltäessä suuria paketteja.
Lyhyestisanottuna ext3:ssa ei ole mitään mikä estäisi fragmentoitumisen tai poistaisi sen kun sitä syntyy. -> Ennemmin tai myöhemmin fragmentoituminen muodostuu ongelmaksi.
Toisilla tiedostojärjestelmillä se tapahtuu ennemmin ja toisilla myöhemmin. Jos se tapahtuu riittävän paljon myöhemmin niin levy on jo menossa vaihtoon liian pienenä ja/tai vanhana ;)
Niputat kyllä kätevästi kaiken fragmentoitumisen yhteen vaikka oikeasti pitäisi keskittyä siihen miten herkästi fragmentoitumista tapahtuu ja minkälaista fragmentoituminen on luonteeltaan.
Ja FAT olisi ihan yhtä hyvä jos joku vain kirjoittaisi sille kunnollisen allokaattorin... On tämä kuultu ennenkin.
Kyllä! Olen kanssasi täsmälleen samaa mieltä kanssasi.
Toisella meistä on tyhjät paristot sarkasmidetektorissa. Minä toistin sinun sanomaasi ilman että allekirjoitin sitä itse...
-
Noh, jokos jollakin on testikokemusta mokomasta ??? ..ja tukeeko Gutsyn kerneli uuttaa ext4:sta - version puolestahan se voisi olla mahdollista...
Linux-today sivuston mukaan EXT4 on suurempi hyppäys EXT3:sta kuin oli aikoinaan siirtyminen EXT2:sta EXT3:een.
-
Lyhyestisanottuna ext3:ssa ei ole mitään mikä estäisi fragmentoitumisen tai poistaisi sen kun sitä syntyy. -> Ennemmin tai myöhemmin fragmentoituminen muodostuu ongelmaksi.
Tuossa on nyt ei-teknisesti ja lyhyesti selvennetty miksi Linux-käyttöjärjestelmän tiedostojärjestelmää (Extended file system) ei tarvitse eheyttää jos ei kiintolevyn tila lopu kesken. Vertauksena on siis FAT32. Ext tiedostojärjestelmän uusin versio on nelonen eli Ext4. Pirstaloituminen on niin vähäistä Ext* tiedostojärjestelmillä että eheytystä ei tarvitse kunhan huolehtii tilan säilymisestä, vaikka asettamalla quotan.
http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting
Se edelleenkään ei tarvitse eheyttämistä jos ei kiintolevy täyty. Itselläni on mm. jo 5 vuotta käytössä ollut 80Gt kiintolevy joka on osioitu alunperin järkevästi niin että /tmp ja /var ovat omina osioina kun niillä on paljon vaihtuvia pieniä tiedostoja ja tietoturva on parempi kun /tmp on omalla osiolla (vaikka nykyisin tmp on yleensä kotihakemistossa oletuksena. Kyseinen kiintolevy on aina ollut alle 80% käytetystä tilasta ja juurikin näin uuden vuoden ensimmäisenä päivänä (jolloin tulee 5 vuotta on tarkalleen tullut täyteen jouluna kun hankittu) pirstaloituminen on 2.6%. Joka viikko kiintolevylle kirjoitetaan n. 30Gt verran tiedostoja, koot vaihtelevat 1-20Mt välillä (RAW valokuvia). Satunnaisesti myös levykuvia ja videoita tulee hetkittäinen editoitavaksi eli n. 300Mt-4Gt välillä. Tiedostojärjestelmä on sattumoisin Ext3. Sanoisin että 2.6% pirstaloituminen on mitään sanomaton.
Sen sijaan FAT32 kiintolevy, ulkoinen LACIE Porche 250Gt kiintolevy kun markkinoille tuli, on nyt vasta 62% käytössä kun ollut varmuuskopiona työtiedostoille. Tiedostoja ei jatkuvasti poisteta / siirretä paljoa kun varmistus on kasvava eikä korvaava mutta tiedostoja silti tulee lisää ja joitakin vanhoja tiedostoja poistetaan. Pirstaloituminen on yllättäen jo yli 21%. Itse nyt en ollut edes ajatellut tätä ja näköjään joudunkin nyt jo tekemään vanhan tempun, siirtämään kaikki tiedostot pois kiintolevyltä ja sitten takaisin niin saa pirstaloitumisen korjattua (koska ei ole mitään Windowsia enkä jaksa alkaa asenteleen LiveCDta joka osaisi FAT32 levyn eheyttää) jota on käytetty joskus *nix tiedostojärjestelmillä hätätilassa kun ei muutoin ole eheytysohjelmille tarvetta.
Ja kun ihmetellään miksi *nix käyttöjärjestelmille kuten Linuxille, ei ole kiintolevyjen eheytysohjelmistoja saatavilla. Syy on yksinkertaisesti se, ei ole tarvetta. Se on sama kuin haittaohjelmien suhteen, ei ole tarvetta virustorjunnalle tai muille haittaohjelmille suojautumisille. Täytyisikö nyt alkaa suunnittelemaan eheytysohjelmat vain sitä varten että jotkut käyttäjät jotka ovat tottuneet entuudestaan tiedostojärjestelmien pirstaloitumiseen, että he voisivat tarkastella ja eheytellä kiintolevyjä vaikka ei ole tarvetta?
Btw. Esim IBM36 koneet oli siitä mainioita, että niiden käyttöjärjestelmä ESTI fragmentoitumisen, niissä siis ei ollut fragmentoitumis ongelmaa.
Käyttöjärjestelmän tärkeimpiä tehtäviä on juurikin tiedostojärjestelmän ylläpito. Ja Linux tekee hommansa erinomaisesti. Mutta käyttöjärjestelmä ei voi tehdä tiedostojärjestelmälle sellaisia temppuja mitä tiedostojärjestelmä itse ei osaa. Tiedostojärjestelmä määrää paljon erilaisia asioita ja käyttöjärjestelmän tehtävä on vain osata suorittaa ne. Sitä vartenhan käyttöjärjestelmä on olemassa että sovelluksien ei tarvitse itse osata kontrolloida laitteistoa.
Käyttöjärjestelmän täytyy olla niin hyvä että se ei pirstaloita tiedostoja kiintolevylle jos vain on mahdollista.
Linux myös vähentää pirstaloitumista käyttämällä tietokoneen keskusmuistia välimuistina. Ensin tiedot nopeaan keskusmuistiin ja sitä mukaan kun aikaa tulee kiintolevylle niin nopeasti saadaan tietoja kiintolevylle niin että se ei koskaan tukkeudu mutta ei myöskään lepää laakereillaan ;-) Tiedostoja ei siis kirjoiteta aina heti vaan sopivissa erissä ja koko järjestelmä pysyy nopeana jatkuvasti kun Linux-käyttöjärjestelmä huolehtii että ne mitkä vaatii aikaa ja tehoja, saava sitä ja muut priorisoidaan niiden alle.
Jos käyttöjärjestelmä estää kokonaan pirstaloitumisen, eli ihan "hard-coded" menetelmällä estetään, siitä tulee vain pahoja ongelmia vastaan tietyissä tilanteissa. *nix käyttöjärjestelmissä kuten Linuxissa, idea on ottaa parhaimmat ideat ja toteuttaa ne. Ei sokeasti seurata vain jotain tiettyä tyyliä koska niin on tehty aikaisemmin, vaan valita paras mahdollinen tapa. Ongelmia syntyy sitten tilanteissa. Koska Linux on suunniteltu palvelimien käyttöjärjestelmäksi jotka toimivat 365/a niin ongelmia ei tule sammutuksissa kuten perustietokoneella joka on muutamia tunteja päivässä käynnissä ja sovelluksia sammutetaan ja käynnistetään ja mikäkin kirjoittaa milloin minnekkin.
Koska sovelluksen ei tarvitse osata kirjoittaa kiintolevylle koska sen tehtävän hoitaa käyttöjärjestelmä, ei sovelluksien tarvitse osata mitään muuta kuin kertoa vain tiedon määrä mikä on tulossa. Ja tätä varten siis sovelluksen on itse vain tiedettävä datan määrä, jonka tiedon se ohjaa käyttöjärjestelmälle. Esimerkiksi bittorrent-asiakasohjelmat saavat tiedon että ladattavan tiedoston koko on X-määrä bittejä. Jos sovellus ei käyttöjärjestelmälle kerro että odotettavissa on tämä X-määrä bittejä, vaan se työntää sitä dataa sitä mukaan kun se tulee, käyttöjärjestelmän oma tehtävä monimutkaistuu. Jo nyt sovellus voi välittää tiedon käyttöjärjestelmälle että bittejä tulee X-määrä ja käyttöjärjestelmä osaakin jo varata tilan virtuaalimuistissa sille. Tietää että se sijoittaa sen Y-paikkaan tiedostojärjestelmässä. Sen sijaan ongelma tuleekin jos bittorrent-asiakasohjelma sammutetaan ja sen jälkeen aletaan kirjoittamaan jotain toista suurta tiedostoa, ei enää Linux-käyttöjärjestelmä tiedä että tilaa tarvitaan ja ladattava tiedosto katkeaa osittain kun myöhemmin käynnistetään taas bittorrent-asiakasohjelma. Jos käyttöjärjestelmä sisältää tiedostojärjestelmän joka tukee varausta, tekee käyttöjärjestelmä samantien varakauksen tiedostojärjestelmään ja se tietää että sinne sitä jatketaan vaikka tietokone sammutettaisiin siinä välissä.
Jokaisen sovelluksen ei tarvitse osata tehdä tilanvarausta kiintolevylle, riittää että juurikin oikeasti osaa kertoa että tarvitsee X-määrän tilaa ja käyttöjärjestelmä varaa tilan tiedostolle. Ktorrent-ohjelmisto itse osaa myös tehdä tilanvarauksen. Se osaa tehdä ihan perinteisen, eli käskee käyttöjärjestelmän tallentaa nollia X-määrä mikä on tulossa ja kirjoittaa aina sitten siihen alueelle. Tämä on hidas tapa. Mutta sitten osataan myös lähettää erityinen pyyntö käyttöjärjestelmälle että mikä tiedostojärjestelmä on kyseessä ja pyytää suoraan käyttöjärjestelmää varaamaan tilan ilman että ruvetaan vain kirjoittamaan nollia. Jos Ktorrent olisi varma että tiedostoja ei kirjoiteta koskaan FAT32 tai muille tiedostojärjestelmille, sen ei tarvitsisi edes nollia kirjoittaa vaan voisi sanoa "X-määrä tietoja tulossa" ja käyttöjärjestelmä tekisi sen. Mutta tämä ei ole aina hyvä asia kun tila varataan niin se on käytetty, oli sitä oikeasti käytetty tai ei. Tuo on yhden tavan likainen fixi "ongelmaan" riippuen miten käyttäjä haluaa homman hoitaa.
Nyt Ext4 -tiedostojärjestelmässä otettiin mukaan ominaisuuksia joita tavallisetkin tietokoneet tarvitsevat. Ehkä tärkeintä on että uusia ominaisuuksia tulee ja joitakin sitten lisättiin kun kerran jotkut toivovat ahkerasti. Minä en jaksa alkaa eheyttämään kiintolevyjä, pidän mielummin vain huolen että en täyteen kiintolevyä päästä jos tallennan ja poistan paljon tiedostoja sieltä.
-
Otin tuosta nyt hieman lukemistoa vielä, että kertaan asiat. Muutkin uteliaat voivat nämä kerrata.
http://ols.108.redhat.com/2007/Reprints/mathur-Reprint.pdf
http://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions
http://kernelnewbies.org/Ext4#head-c212d1622081e592caa73b9e14511cee45fb989b
Täytyy myöntää että iNode homma ei ole mennyt ihan vielä täysin jakeluun, pitänee lukea siitä erillistä dokumentointia hiemna. FAT,FAT32 ja NTFS ovat kyllä varsin tuttuja.
-
FAT,FAT32 ja NTFS ovat kyllä varsin tuttuja.
Löytyykö sinulta mitään tietoa, faktaa tai dokumenttia siitä miten NTFS oikeasti toimii? Jotain artikkelia jossa mennään hieman pintaa syvemmälle ja käsitellään edes pintapuolisesti käytettyjä tietorakenteita ja toimintaperiaatteita?
-
Löytyykö sinulta mitään tietoa, faktaa tai dokumenttia siitä miten NTFS oikeasti toimii? Jotain artikkelia jossa mennään hieman pintaa syvemmälle ja käsitellään edes pintapuolisesti käytettyjä tietorakenteita ja toimintaperiaatteita?
Ei mitään havaintoa mistä hommasin, varmaan TPB:stä jonkun computer ebooks paketin mukana tuli. Siinä oli lyhyehkö noin 30 sivuinen kuvaus NTFStä. Eli siitä mikä on perusrakenne ja miten pakatut tiedostot toimivat, efs, sparce filet miten useat datastreamit. Se mikä jäi vähän hämärän peittoon (ehkä riittämättömän ajattelutyön tuloksena) oli se, miten esimerkiski datarakenteita externalisoidaan pointtereilla. Joka tuntui olevan NTFSssä varsin normaali toiminto. Tuo saattoi vielä tapahtua toistuvasti, eli pointterit viittaa pointtereihin jne. Tuon kautta MFT myös suurenee kun tiedot eivät mahdu enään varattuun zoneen. Samoin kerrottiin miten MTF:n koko määrittyy alkunperin. EFStä mulle jäi esimerkiksi se epäselväksi miksi käytännössä näkyy yleensä temp tiedosto ennen lopullisen tiedoston syntymistä efs:n kanssa, ilman sitä tuota ilmiötä ei näy. EFSssä siis on tiedostokohtainen aes256 salaus ja avain on tallennettu RSAn kautta. Mielestäni tuo on suhteellisen hyvä ratkaisu. Näin ollen kun tuo privaattiavaimella salattu salausavain tuhotaan ei ole enää tarvetta wipellä pyyhkiä tiedostoa kun sen salausavain on pysyvästi hukassa. (Jos ei sitten käytä foliohattua, silloin tarvitaan vielä 35 ylikirjoitusta.)
Tuo siis oli "toiminnallinen kuvaus" muutamilla teknisillä referensseillä, ei niinkään täydellinen teknien speksi. Usein pyrinkin lukemaan tuollaisia 10-30 sivuisia dokumentteja erilaisista asioista. Ne antavat kohtuullisen yleiskuvan, mutta yksityiskohtiin ei kannatakkaan tuon syvemmälle mennä ellei siihen ole jotain oikeaa tarvetta. Samanlaisia varsin mielenkiintoisia papereita on julkaistu esim MapReducesta, GFStä, BigTablesta etc. Antavat yleiskuvan, mutta eivät paljasta liikesalaisuuksia. Jos sulla on MSDN käytössä, sieltä voisi löytyä parempaa infoa.
Fatti taas oli niin helppo, että sen kanssa on tullut vuonna miekka ja kilpi leikittyä hexa editorin kanssa. Totta on että suorituskyky varsinkin suurilla hakemistoilla on aika surkea. Mutta kuten tuosta ext3:sta todetaan. Vaikka se ei ole paras mahdollinen ratkaisu, se tarjoaa useinmiten riittävän toiminnallisuuden kuten edellinen Fri13 totesi. Monesti monimutkaisia ja kalliita ratkaisuita ei kannata lähteä tekemään jos vanha kerran toimii. VFAT varsinkin on jotain aivan järkyttävää purkkaliimaa, kun katsoo levyä hexa editorilla selviää mistä virityksestä on kyse. Lisäksi jos luulet että formatointi / tyhjentäminen ja tietojen uudelleenkopiointi levylle johtaa fragmentoitumattomaan tulokseen olet väärässä. MIkäli jossain hakemistossa on edes kymmen tiedostoa ja käytät pitkiä tiedostonnimiä on varmaa että tuo hakemisto fragmentoituu levylle. Näin ollen ensin pitäisi luoda nollatavuiset tiedostot ja hakemistot ja vasta sitten data. Kuten tuolla aikaisemmin sanoinkin.
Elihän fattikin varsin pitkään puuteistaan huolimatta. Parannus tulee vasta kun vanhan ratkaisun kanssa törmätään seinään, tai kilpailija esittää jotain ratkaisevasti parempaa joka herättää myös asiakkaiden huomion.
Fri13:ta tiedoksi, kyllä. Ext3n allokointi pitää homman kassa varsin pitkään, mutta kun fragmentoitumista ja sitähän tapahtuu, niin nykyisessä järjestelmässä ei ole mitään menetelmää sen poistamiseen. Levyjen täyttymistä sattuu päivittäin. Riippuen testin tyypistä, tämä on ongelma, se ei ole ongelma lainkaan, tai jotain siltä väliltä. Olen varsin hyvin perehtynyt linkkiin jonka laitoit. Eikä se tarjoua mitään menetelmää fagmentoitumisen estämiseksi. Muuta kuin hypetystä sellaisille ihmisille, jotka eivät ymmärrä miten fragmentoituminen jatkossa muodostuu tuon suppean esimerkin jälkeen. Tyypillistä insinöörityötä siis. Minun yleisimmin esittämä kysymys erilaisille suunnittelijoille on MITÄ SITTEN. Mitä tapahtuu sen jälkeen, kun olette käyneet teidän suppean esimerkin läpi. Monista ohjelmista puuttuu esimerkiksi järkeenkäyvät purge toiminnot, kun ei niitä koskaan ajateltu. Eikö se riitä että tietoa voi lisätä.
Kirjoitin yhden sovelluksen jossa käytin data rakenteena proof of conseptissa linked listiä. POC meni sitten suoraan tuotantoon. Kun kuulin pitkistä suoritusajoista, kysyin esimiheletäni että korjataan. Vastaus oli lyhyt, kun asiakas ei ole valmis maksamaan muutoksesta tuhansia euroja, ei korjata mitään. Äkkiäkös ton linked listin olisi korvannut hashtablella. Suoritusaika olisi pudonnut varmasti sadasosaan noilla tietorakenteilla. Mutta kun ei makseta, niin ei myöskään korjata. Voidaan siis todeta että yli 99% suoritusnopeuden kasvu ei ollut ongelma, kun siitä ei oltu valmiita maksamaan.
-
Tämä oli siis loistava dokkari, suosittelen kaikkia lukemaan tämä. http://ols.108.redhat.com/2007/Reprints/mathur-Reprint.pdf siinä asiat on käyty kunnolla läpi, eikä ole tehty jotain yksinekertaistettua epäselvää diibadaabaa, kuten noissa niin monissa ext3 doesn't need defrag roska dokumenteissa on ollut. Em. dokumentista käy myös hyvinselvästi ext3:n puutteet ilmi.
Käytyäni vielä kerran nuo dokumentit läpi täytyy todeta, että... Ext3 ei siis tue viivästettyä allokointia, eikä se TUE koko tiedoston tai edes sen osan allokointia yhtenäisenä kertavarauksena. Nuo ovat molemmat ext4:n ominaisuuksia. Tätä koitin jo aikaisemmin selittää. Kun aikaisemmin viittasin sovellusten tukeen, viittasin siihen että sovellusten pitäisi aina varatessaan levytilaa kertoa tarvittava tila, mikäli se suinkin on mahdollista. Jos tätä ei käytetä, on fagmentoitumista täysin mahdotonta välttää kun tiedostot kasvavat. Kävin läpi noita referenssä, Delugella tulee helposti todellakin 80% täydelle levylle (50 gigaa vapaana) esim. 10000 epäyhtenäistä pätkää kun lataa 700 megan tiedoston. Jos tuo ei ole fagmentoitumista, niin mikä on? Tietysti on mahdollista että vapaan tilan fagmentoituminen silti estäisi yhtenäisen varaamisen. Mutta pätkiä pitäisi silti syntyä huomattavasti vähemmän kun varataan mahdollisimman suurai yhteinäisiä tiloja. Tosin sitten ne isot yhtenäiset tilat on syöty jo seuraavaa isoa tiedostoa varten.
Ext3:n dokumentoinnissa sanotaan aivan selvästi, että levytilaa voidaan varata vain ja ainoastaan 4 kilon blokeissa. Ei yhtään suuremmissa. Joten siinä käy juuri kuten esimerkissäni kerroin Kutsutaan N kertaa tuota 4 kilon handlea, jotta saadaan tarvittava koko aikaiseksi. Kyse ei siis ole koko tilan keralla varaamisesta vaan toistuvasta loopista. Näin ollen levyjärjestelmän on mahdotonta alussa tietää tarvittava levytila ja tehdän sen pohjalta myös oikea päätös tallennuspaikasta.
Ihme kun ihmiset jänkkää vastaan eivätkä osaa lukea noita dokumentteja. ;) Varsinkin UbuntuForumssissa näitä oli paljon. Uskovat sokeasti kaiken mitä sanotaan perehtymättä asiaan itse. Vaikka asian selitti, kuten tässäkin threadissa. Niin silti laitetaan vielä referenssiä kuten Fri13 teki. ;) Eikä itse vaivauduttu edes ajattelemaan sen verran että huomattaisiin referenssin olevan puutteellinen.
Ext3 järjestelmässä on siis täysin sama, avataanko tiedosto, lisätään siihen 4 kiloa ja suljetaan tiedosto. Vai varataanko "kerralla" esim 4 gigaa, koska matalan tason järjestelmässä menettely on edelleen täysin sama. Tämä yhdistettynä tuohon malliin joka "muka" estää fragmentoitumisen, nimenomaan vahvistaa sen että fragmentoitumista syntyy aivan varmasti. Eikä toisaalta ole mitään järjestelmää joka sen jälkeen poistaisi syntyneen fragmentoitumisen.
Sanokaa nyt että olen väärässä. Kukaan ei vielä näitä ole kumonnut. Kaikki on vaan laittaneet linkkejä noihin höpöhöpö esityksiin joista puuttuu sekä ykstyiskohdat että loppuunasti viety ajattelu asiaan liittyen.
Samalla painotetaan myös faktaa jota painotin aikaisemmin. Eli allokaattori EI vaiktua levyn formaattiin. Se millaita allokaattoria esim FATin kanssa käyttää, on sitten ihan toinen juttu. Sen kanssa voitaisiin käyttää täysin samaa allokaattoria kuin ext3:n kanssa. Tosin kuten todettu, sekin on kaukana täydellisestä.
Ext4 siis fragmentoituu huomattavasti vähemmän kuin Ext3 noiden muutaman ominaisuuden (mballoc, delayed alloc, extents, persistent preallocation) ansiosta jos sovellukset niitä käyttää. Silti ext4: on implementoitu Online defragmentation ominaisuus. Miksi? Sehän piti olla täysin tarpeeton ja vielä huomattavasti vähemmän tarpeellinen kuin Ext3:n tapauksessa. Dokumentoinnissa sanotaan, että edes nuo ominaisuudet eivät estä fragmentoitumista. Referenssi e4defrag.
P.S. Mulla on kyllä pitkä kokemus tällaisista asioista sovelluskehittäjien kanssa taistelemisesta. ;) Sekä yleensä hyvänäkemys siitä kun määritellään jotain, mitä puutteita siihen jää. Sekä miten ne puutteet saadaan tuotua esiin käytännössä.
Muita hauskoja papereita luettavaksi on muuten esim uTorrentin Compact allocation. Jotkut väitti että se tehostaa levytyöskentelyä, mun mielestä se johtaa lähinnä siihen että samaa dataa joudutaan lukemaan ja kirjoittamaan monta kertaa. En tiedä voiko sitä tehostamiseksi kutsua.
GNUnetissä oli myös jossain vaiheessa pelkkä CacheMigration routine, ei mitään PurgeRoutinea. Oli pakko vääntää kehittäjille rautalangasta, että kun cache tulee täyteen eikä sitä koskaan putsata niin se romuttaa verkontoimintakyvyn cachen toimimattomuuden kautta, ellei jatkuvasti liity uusia nodeja tai käyttäjät eivät manuaalisesti tuhoa koko cachea. Cachesta siis kannattaa purgeta tietyllä rutiinilla dataa jota ei ole käytetty. Testiverkossa ja isolla cachella ja pienellä datamäärällä tuo ei tietenkään ollut ongelma.
-
Heitän pohdittavaksi pari seikkaa fragmentoitumiseen ja defragmentoimiseen liittyen.
Vaikka, ainakin teoriassa, ext3-levy fragmentoituu, ei se käytännössä näytä pitkässäkään ja monipuolisessa käytössä pienillä ja suurilla tiedostoilla hidastavan järjestelmän toimivuutta; ainakaan kun vapaata tilaa on selvästi yli 50 % levystä.
Täydemmistä levyistä minulla ei ole kokemusta.
Win:n NTFS alkaa vakavasti hidastua fragmentoitumisen johdosta melko pian jo vain 30%:sti kirjoitetuilla levyillä.
WinXP kun yritää ylläpitää nopeutta kirjoittamalla käytettyihin psosesseihin liittyviä tiedostoja uudelleen levyn (c:) keskiosaan (prefetch-kansio).
Tämä kansio on aika ajoin tyhjennettävä manuaalisti ja defragmentoitava levy.
Tämä tiedostojen siirto Win:n toimesta levyn keskelle ja defragin toimesta taas takaisin levyn alkuun kuluttaa turhaan levyn samoja kohtia jatkuvalla kirjoittamisella.
Levyä tulisi käytää tasapuolisesti joka kohdasta.
Toisaalta Win-logiikka (prefetch) lähtee siitä, että levyn keskiosa on lukupäälle nopeiten tavoitettavissa (lukunopeus paranee).
Tämä taas toisaalta juuri aiheuttaa fragmentoitumista. Ja siis hidastaa.
Ext4-järjestelmää tulee varmaan kokeiltua, kun se saadaan toimimaan.
Tällä hetkellä ei ole täyttä varmuutta esim. tiedostojen säilymisestä.
Sen sijaan tiedetään, että boot-osion formatointi ext4:ksi on ongelma.
Pitää siis odotella ja sillä välin käyttää ext3:a.
-
Ext3 järjestelmässä on siis täysin sama, avataanko tiedosto, lisätään siihen 4 kiloa ja suljetaan tiedosto. Vai varataanko "kerralla" esim 4 gigaa, koska matalan tason järjestelmässä menettely on edelleen täysin sama.
On siinä se ero että kerralla varattaessa saadaan todennäköisemmin yhtenäisiä alueita kun muita tiedostoja ei päästä kirjoittamaan väliin. Tältäkään osin asia ei liene aivan näin yksinkertainen sillä juuri tehdylle varaukselle on voitu jättää kasvuvaraa eikä ole mitenkään itsestään selvää että toinen tiedosto kirjoitettaisiin alkuperäisen tiedoston perään.
Tämä yhdistettynä tuohon malliin joka "muka" estää fragmentoitumisen, nimenomaan vahvistaa sen että fragmentoitumista syntyy aivan varmasti. Eikä toisaalta ole mitään järjestelmää joka sen jälkeen poistaisi syntyneen fragmentoitumisen.
Millaista syntyvä fragmentoituminen on luonteeltaan?
Tein pienen kokeilun pakkaamalla 7zip:n avulla paketin jonka pakatuksi kooksi tuli noin 8,6 GB. Kohdeosio on melko tuore ja sillä on runsaasti vapaata tilaa. Minulla ei ollut mitään sopivampaakaan osiota tällaisen testin tekemiseen sillä pääasiassa minulla on käytössä reiserfs ja jfs. Pakkaamisen aikana osille kopioitiin myös muita tiedostoja mutta en usko niiden vaikuttaneen lopputulokseen.
$ sudo filefrag TEST.7z -v
Password:
Checking TEST.7z
Filesystem type is: ef53
Filesystem cylinder groups is approximately 238280
Blocksize of file TEST.7z is 4096
File size of TEST.7z is 9278810983 (2265335 blocks)
First block: 124928
Last block: 2397029
[...]
TEST.7z: 104 extents found, perfection would be 70 extents
Tiedosto on 104 palasessa ja 34 niistä on ylimääräisiä (eli optimitilanteessa tiedosto olisi 70 palasessa). Huomattavasti mielenkiintoisempi tieto on viimeisen ja ensimmäisen lohkon välinen etäisyys joka on 2.272.101 lohkoa. Kun tästä vähennetään tiedoston tarvitsemat lohkot niin välissä on 6.766 ylimääräistä lohkoa eli alle 26,5 MB. Ei tunnu kovin pahalta kun ottaa huomioon tiedoston koon.
Joku voisi tehdä vastaavan testin hieman täydemmällä levyllä.
Samalla painotetaan myös faktaa jota painotin aikaisemmin. Eli allokaattori EI vaiktua levyn formaattiin. Se millaita allokaattoria esim FATin kanssa käyttää, on sitten ihan toinen juttu. Sen kanssa voitaisiin käyttää täysin samaa allokaattoria kuin ext3:n kanssa. Tosin kuten todettu, sekin on kaukana täydellisestä.
Oletko varma että ext3:n allokaattori ei ole riippuvainen tiedostojärjestelmän tietorakenteista tai vaihtoehtoisesti että FAT:n tietorakenteet tukevat niitä ominaisuuksia joita ext3:n allokaattori tarvitsee?
Silti ext4: on implementoitu Online defragmentation ominaisuus.
Ei sitä vielä stablen julkaisun yhteydessä ollut valmiina ;)
Dokumentoinnissa sanotaan, että edes nuo ominaisuudet eivät estä fragmentoitumista.
Ei kai kukaan ole väittänytkään ettei fragmentoitumista tapahtuisi (ja jos on niin heidät voi jättää huomiotta). Kysymys on siitä miten paljon fragmentoitumista tapahtuu ja miten se vaikuttaa suorituskykyyn.
-
Ext4-järjestelmää tulee varmaan kokeiltua, kun se saadaan toimimaan.
Tällä hetkellä ei ole täyttä varmuutta esim. tiedostojen säilymisestä.
Oletko tosissasi? Ei kai stablessa tuollaisia ongelmia pitäisi olla?
Sen sijaan tiedetään, että boot-osion formatointi ext4:ksi on ongelma.
Mikä ongelma tässä on? Grub:sta puuttuva tuki ext4:lle? Tosin boot-osion tiedostojärjestelmällä ei ole hirveästi merkitystä. En näe mitään syytä miksi joku haluaisi käyttää ext4:ää boot-osiolla.
-
Oletko tosissasi? Ei kai stablessa tuollaisia ongelmia pitäisi olla?
Mikä ongelma tässä on? Grub:sta puuttuva tuki ext4:lle? Tosin boot-osion tiedostojärjestelmällä ei ole hirveästi merkitystä. En näe mitään syytä miksi joku haluaisi käyttää ext4:ää boot-osiolla.
Ongelma yksinkertaisuudessaan on se, että se edellyttää melkoista "sävellystä" eikä lopputuloksena ole kovin yksinkertainen ratkaisu.
Kuinka varma, mgronber, olet, että käytännössä tapahtuu paljonkaan muutoksia ext3:een verrattuna, etenkään jos käytössä on nopealevyinen pöytäkone ja suuri kapasiteetti, joka jättää paljon tyhjää tilaa?
Minkälaisissa kokoonpanoissa katsot, mgronber, hyödyn ext4:stä olevan merkittävän?
1. Tässä pari lainausta:
A) http://ext4.wiki.kernel.org/index.php/Ext4_Howto (http://ext4.wiki.kernel.org/index.php/Ext4_Howto) 9.8.2008
"As of this writing (mid-July, 2008, just after the release of 2.6.26), the ext4 code is functionally complete and functional enough that a few people are using it in production. However, it is still being tested and although the developers haven't lost any data yet, please be cautious and keep plenty of backups!
For people who are running Ubuntu, it is *highly* recommended that you download a set of modified util-linux packages and install them. Packages for Ubuntu Hardy are available here. These packages revert a change made by Ubuntu to use the volid library instead of the blkid library. The volid library has a number of shortcomings, including that they don't work on freshly created filesystems or swap devices until after you reboot (since it is tied to udev probing) and the volid library doesn't understand ext4dev filesystems. The blkid library is much better, and Debian uses the blkid library for util-linux. Unfortunately, Ubuntu chose to make this reason for some unknown reason. For other versions of Ubuntu, the patch that was applied can be found here."
B) http://kernelnewbies.org/Ext4 (http://kernelnewbies.org/Ext4) 27.12.2008
"This is the first stable version of Ext4, so even if the whole development and release of this filesystems has been slowed down and delayed a lot to guarantee the same level of stability that you'd expect from the current Ext3 implementation, the usual rules of any ".0" software apply.
One very important thing to keep in mind is that there is NOT Ext4 GRUB support. Well, that wasn't exactly true: There is grub support, but the grub versions used by your current distro don't support it. There's support in the GRUB2 development branch, but only from this commit and ahead. There're available grub2 packages in Ubuntu and debian-derived distros as the grub-pc package. In the 0.9x branch, there's not official support, but there's a Google SoC project that developed support for it, and Google finds patches. So choose yourself. The next release of distros based in Linux 2.6.28 will probably have support in one way or another. The safe option is to keep your /boot directory in a partition formatted with Ext3.
You also need an updated e2fsprogs tool, of course, the latest stable version -1.41.3- is recommended.
NOTE: At least in debian-derived distros, including Ubuntu, converting your filesystem to Ext4 when using a initramfs results into a non-booting system, apparently even when you enable the "ext4dev compatibility" option". The problem is that the fstype klibc util detects the ext4 filesystem as ext3, and tries to mount it as ext3, and fails. The fix is to pass the "rootfstype=ext4" option (without the quotes) in the kernel command line."
2. Minusta on kyllä ongelma, jos joudun osioimaan erillisen boot-osion.
Nythän on kätevintä käyttää boottaavaa root-osiota (siis boot- ja root-osio samassa).
Lisäksi dual-bootin (esim. Linux - Win) tekeminen saattaa aiheuttaa päänvaivaa erillisellä boot-osiolla.
Näinhän on joillekin täällä foorumissa jo käynytkin.
Ja tähän root-osioonhan tätä ext4:ää kai tarvitaan.
Kun haluaa pitää bootin root-osiossa, jää ext4:lle vain home-osio.
En nimittäin lähtisi osioimaan erikseen rootin kansioita (esim. var, usr) ihan hankaluuden takiakaan.
-
Oletko tosissasi? Ei kai stablessa tuollaisia ongelmia pitäisi olla?
Mikä ongelma tässä on? Grub:sta puuttuva tuki ext4:lle? Tosin boot-osion tiedostojärjestelmällä ei ole hirveästi merkitystä. En näe mitään syytä miksi joku haluaisi käyttää ext4:ää boot-osiolla.
Ongelma yksinkertaisuudessaan on se, että se edellyttää melkoista "sävellystä" eikä lopputuloksena ole kovin yksinkertainen ratkaisu.
Olet lainannut kahta eri asiaa käsittelevät kappaleet. Mihin sana "se" viittaa?
Kuinka varma, mgronber, olet, että käytännössä tapahtuu paljonkaan muutoksia ext3:een verrattuna, etenkään jos käytössä on nopealevyinen pöytäkone ja suuri kapasiteetti, joka jättää paljon tyhjää tilaa?
Paha sanoa kun ei minulla ole tuosta vielä mitään kokemuksia. Sitä paitsi minua kiinnostavat siinä eniten toissijaiset ominaisuudet kuten journalin tarkistussumma ja nopeampi tiedostojärjestelmän tarkistus. Muut ominaisuudet ovat vain bonuksia.
Minkälaisissa kokoonpanoissa katsot, mgronber, hyödyn ext4:stä olevan merkittävän?
Ainakin sellaisissa kokoonpanoissa joissa osiokoko ylittää 8 TiB.
"As of this writing (mid-July, 2008, just after the release of 2.6.26), the ext4 code is functionally complete and functional enough that a few people are using it in production. However, it is still being tested and although the developers haven't lost any data yet, please be cautious and keep plenty of backups!"
Ei tuo nyt kovin vakavalta kuulosta.
One very important thing to keep in mind is that there is NOT Ext4 GRUB support.
Eli asia oli juuri niin miten epäilinkin.
Nythän on kätevintä käyttää boottaavaa root-osiota (siis boot- ja root-osio samassa).
Lisäksi dual-bootin (esim. Linux - Win) tekeminen saattaa aiheuttaa päänvaivaa erillisellä boot-osiolla.
Kenelle aiheuttaa kenelle ei. Minulla ei ole koskaan ollut tuon kanssa mitään ongelmia.
Ja tähän root-osioonhan tätä ext4:ää kai tarvitaan.
Kun haluaa pitää bootin root-osiossa, jää ext4:lle vain home-osio.
Minusta kotikoneissa ext4 on tärkeämpi niillä osioilla joilla sijaitsee käyttäjien tiedostoja. Siellä voi olla paljon vaihtuvuutta ja suuria tiedostoja.
En nimittäin lähtisi osioimaan erikseen rootin kansioita (esim. var, usr) ihan hankaluuden takiakaan.
Riittää kun osioi erikseen /boot:n niin ei tarvitse tehdä asioista vaikeita.
-
1. Olet lainannut kahta eri asiaa käsittelevät kappaleet. Mihin sana "se" viittaa?
2. Ainakin sellaisissa kokoonpanoissa joissa osiokoko ylittää 8 TiB.
3. Minusta kotikoneissa ext4 on tärkeämpi niillä osioilla joilla sijaitsee käyttäjien tiedostoja. Siellä voi olla paljon vaihtuvuutta ja suuria tiedostoja.
4. Riittää kun osioi erikseen /boot:n niin ei tarvitse tehdä asioista vaikeita.
Numeroin nuo kommenttis, mgronber, että olisi helpompi kommentoida:
1. Niin, viittasin vain yleisesti ext4-järjestelmän käyttöönottoon tuolla sanalla "se".
Lähinnä nyt tarkoitin ext3 -> ext4 -muunnosta.
2. OK, tuo on ihan uskottava ilmaisu. Itselläni koko kovalevy on "vain" 320 Gb eli 0,32 Tb.
3. Joo tottakai home-osiolla näitä asetustiedostoja (jotka ovat yleensä hyvinkin pieniä) on runsaasti.
Lisäksi on tietenkin paljon erikokoisia omia tiedostoja pikkukuvista (thumbnail) suuriin videotiedostoihin asti.
Mutta siten niiden vaihtuvuus ja käytännön fragmentoituminen, no ehkä riippuu käyttäjästä.
Windowsin pilkkoutuminen koskee nimenomaan järjestelmätiedostoja, mutta tämähän nyt ei liity ext3-ext4 -keskusteluun.
4. Niin erillinen boot-osio riittää kyllä.
Tosin se juuri jo on joillakin aiheuttanut ongelmia dual-bootin luomisessa.
Muistan ainakin tapauksen, jossa ensin oli asennettu vanhempi Ubuntu-distro (omilla boot/root/home -osioilla) ja sitten asennettiin lisäksi uudempi Ubuntu distro (millä osioinnilla?).
PS. Tietenkin siinä vaiheessa, kun GRUB-ongelma on ratkaistu helppoon lopputulokseen johtavasti, otan itsekin käyttöön ext4-järjestelmän.
Ja teen tuon puhtaalle, tyhjälle kiintolevylle, esim. live-USB:llä ensin formatoimalla.
Nythän vielä Jauntyn alfa2-live ei kykene ext4:ää edes luomaan.
-
Minkälaisissa kokoonpanoissa katsot, mgronber, hyödyn ext4:stä olevan merkittävän?
Sitä en täsmälleen tiedä. Mutta monipuolisten benchmarkkien jälkeen ilmoittivat tuossa PDF:ssä jota lainasin, että tiedonsiirtonopeus samalla raudalla oli ext4:lla 35% parempi kuin ext3:lla. Lisäksi prosessorikuormitus oli 50% pienempi. Mielestäni nuo ovat ainakin palvelinympäristössä merkittäviä tekijöitä. (Pitää myöntää, että useimmille kotikäyttäjille on ihan sama miten asiat toimii, kunhan ne vain toimii.)
Uskoisin että tuollaisen työryhmän tekemä testi on ihan pätevä ja antaa paremman kuvain kuin esimerkiksi omalla koneella tehty yksittäinen testi.
-
Olen varsin hyvin perehtynyt linkkiin jonka laitoit. Eikä se tarjoua mitään menetelmää fagmentoitumisen estämiseksi.
Sitten ehdotan että luet sen uudelleen koska et huomannut sitä erästä menetelmää joka mainittiin ja joka oikeasti vähentää tiedostojärjestelmän pirstaloitumista ja eheytystyökalujan tarpeellisuutta.
Tämä oli siis loistava dokkari, suosittelen kaikkia lukemaan tämä. http://ols.108.redhat.com/2007/Reprints/mathur-Reprint.pdf siinä asiat on käyty kunnolla läpi, eikä ole tehty jotain yksinekertaistettua epäselvää diibadaabaa, kuten noissa niin monissa ext3 doesn't need defrag roska dokumenteissa on ollut. Em. dokumentista käy myös hyvinselvästi ext3:n puutteet ilmi.
Ei kyllä ollut loistava, sanoisinkin että raapaisu Ext4-tiedostojärjestelmään. Ideoiden toimintatapaa ja muuta vastaavaa selitetty teknisesti mutta teoreettisesti. Ext3:n puutteita ei mainittu kuin parissa otteessa joilla oikeastaan vieläpä viitattiin samalla muihin tiedostojärjestelmiin. Puhuttiin Ext4:n uusista päämääristä joilla vähennetään joidenkin ongelmien esiintymistä tietyissä tilanteissa, ei poisteta kokonaan. Suosittelenkin että luet dokumentin uudelleen. Minun piti ihan kahdesti lukea se että varmistuin siitä että siinä ei mitään vakavia Ext3:n puutteita tuoda ilmi peruskäytössä, vain äärimmäisissä tilanteissa kuten 1EB tilantarpeissa palvelimissa. Tietenkin jos haluaa vain teoriaa ja käsitellä aihetta murto-osassa tapahtuvissa tilanteissa niin siitä vain.
Käytyäni vielä kerran nuo dokumentit läpi täytyy todeta, että... Ext3 ei siis tue viivästettyä allokointia, eikä se TUE koko tiedoston tai edes sen osan allokointia yhtenäisenä kertavarauksena. Nuo ovat molemmat ext4:n ominaisuuksia.
Onko joku väittänyt että Ext3 sisältäisi samat ominaisuudet mitä Ext4 vasta on nyt vakaana versiona tuonut? Eihän Ext3, eli tuo tiedostojärjestelmä sitä tue, mutta ne voidaankin hoitaa muulla tavoin, kuten dokumentissakin kerrotaan. En tiedä jätitkö sen kohdan lukematta myös. Tässä tapauksessa Ext4 parannus on juuri se että käyttöjärjestelmä pystyy suorittamaan operaatiot, eikä ohjelman tarvitse siitä itse huolehtia. Kuten mainitsin aiemmin.
Näin ollen levyjärjestelmän on mahdotonta alussa tietää tarvittava levytila ja tehdän sen pohjalta myös oikea päätös tallennuspaikasta.
Suosittelen lukemaan uudelleen esim Ext3-tiedostojärjestelmää koskevia dokumentteja niin löydät että tuokin menee osittain väärin ;-)
Ihme kun ihmiset jänkkää vastaan eivätkä osaa lukea noita dokumentteja.
& Uskovat sokeasti kaiken mitä sanotaan perehtymättä asiaan itse. Vaikka asian selitti, kuten tässäkin threadissa. Niin silti laitetaan vielä referenssiä kuten Fri13 teki. Wink Eikä itse vaivauduttu edes ajattelemaan sen verran että huomattaisiin referenssin olevan puutteellinen.
En sitten tiedä mikä oli kun et huomannut antamastani linkistä alussa mainittua asiaa, että se ei ole _tekninen_ ja tarkka selostus, vaan rautalangasta väännetty tavalliselle käyttäjälle joka haluaa vain tietää mitä teknisessä dokumentaatiossakin selitettäisiin ja mitä ne henkilöt jotka ovat Ext* -tiedostojärjestelmiä ja Linux-käyttistä ohjelmoineet, kertovat syyksi että eheytystyökaluja ei tarvita. Kummallista peräti sanoisin. Mutta perustan sanomiseni vain niihin faktoihin, eli tapauksiin joita tullut vastaan ja en puhu mistään oman pöytäkoneen tapauksista, mitä esimerkkinä käytin aikaisemmassa viestissä. Mielestäni myös asioista voi yrittää kertoa tavalliselle käyttäjälle joka seuraa ketjua, että mistä on oikeasti kyse. Voisihan tätä keskustelua alkaa käymään tarkasti tieteellisin tekstein, mutta se muuttuu pian muille kuivaksi ja tylsäksi jos ei ole termit tuttuja. Tiedostojärjestelmistä ylipäätänsä puhuminen vaatii että keskustelu rajataan tarkkaan jollekkin tietylle tiedostojärjestelmälle ja silloin vielä tiettyyn asiaan. Ominaisuuksien laatu kun vaihtelee hyvinkin paljon riippuen käyttöympäristöstä.
Ext4 siis fragmentoituu huomattavasti vähemmän kuin Ext3 noiden muutaman ominaisuuden (mballoc, delayed alloc, extents, persistent preallocation) ansiosta jos sovellukset niitä käyttää. Silti ext4: on implementoitu Online defragmentation ominaisuus. Miksi? Sehän piti olla täysin tarpeeton ja vielä huomattavasti vähemmän tarpeellinen kuin Ext3:n tapauksessa. Dokumentoinnissa sanotaan, että edes nuo ominaisuudet eivät estä fragmentoitumista.
Otitko huomioon että keskustelussa ei kukaan väittänyt, että Ext3-tiedostojärjestelmä ei pirstaloidu? Kysymys oli, tarvitseeko käyttää eheytystyökaluja vai ei. Kuten itsekkin annoin ihan malliesimerkin tämän hetkisestä /peruskäytöstä/ niin tukevat perinteistä asiaa, eli ei tarvitse.
Pirstaloitumista tapahtuu kaikilla tiedostojärjestelmillä, joillakin vähemmän ja joillakin enemmän. Pirstaloitumista myös tapahtuu reippaasti enemmän väärin configuroiduissa hakemistorakenteissa kuin oikein configuroiduissa että suurissa palvelinryppäissä kuin pöytätietokoneissa. Pirstaloitumisen tasoon vaikuttaa tilan määrä ja tiedostot joita sinne kirjoitetaan.
Se on pelkkää matematiikkaa ja sillä voidaan aina todistaa että oli mikä tahansa tiedostojärjestelmä, pirstaloitumista tapahtuu n-ajassa kun X-tilaan tallennetaan Y-määrä z-kokoisia tiedostoja. Tietyillä tavoilla (kuten ollaan jo useasti tiedostojärjestelmien ominaisuuksissakin todettu), pirstaloitumisen määrä kyllä saadaan niin pieneksi että se ei ole haitallinen tekijä. Kukaan ei kiellä että pirstaloitumista /ei tapahdu/ vaan että se määrä on peruskäytössä niin vähäistä että työkaluja siihen ei tarvita. Ainahan voit kertoa että miksi niitä eheytystyökaluja ei ole vieläkään saatavilla jos kerran se pirstaloituminen on niin vakavaa että niille olisi tarvetta? Joku salaliitto että ei voida myöntää että Ext3 on huono mikä tapahtuisi jos eheytystyökalut julkaistaan. Sen sijaan kehitelläänkin Ext4 joka korjaakin ne ongelmat joita Ext3 mukamas ei omaa? Jos luet sen dokumentin uudelleen, huomaat että siinä puhutaan tiedostojärjestelmän pirstaloitumisen vähentämisestä tilanteissa joissa sitä hyvin paljon tapahtuu, palvelinkäytössä. Myös ominaisuuksista jotka kasvattavat riskiä tiedostojen pirstaloitumiselle (ei tarkoita että kasvattaa pirstaloitumista, vaan riskiä!)
Minä en myöskään voi asialle mitään, että omien kokemuksien mukaisesti, jotka tukevat tuota tietoa että eheytystyökaluja ei tarvita, pirstaloituminen on ollut niin vähäistä että eheyttäminen olisi vain turhaa. Minä en voi myöskään mitään sille, että kun on tehnyt tiedostojen kopioinnin, vastaavanlaiselle levylle mutta tyhjälle. On se pienikin pirstaloituminen tullut korjattua. Tarkennan vielä että en ole tehnyt dd:lla mitään bittitarkkaa kloonia, jolloin pirstaloituminenkin kopioitaisiin juurikin sellaisena uudelle levylle. Olkoot vaikka miten "virheellistä", niin kummallisesti vain aina toiminut juuri kuten mainitsin. RAID-levypakoissa taas toiminto ei ole niin hyvä kun pirstaloitumista tapahtuu vieläkin herkemmin mitä suuremmista tilanmääristä puhutaan, laskien kiintolevyjen, levyjen, tiedostojärjestelmien ym yhtälöt.
Teoriassa voidaan puhua asista vaikka kuinka paljon, tuolloin voidaan todeta että Ext3 pirstaloituu että se täytyy saada eheytettyä. Mutta jos se normaalissa käytössä on alle 3% luokkaa niin voidaan kyllä alkaa jankkaamaan siitä, onko se pahasta vai onko hidastaako se vielä yhtään levytoimintoja. Voimme myös alkaa keskustelemaan eri tiedostojärjestelmien sopivuudesta eri osiin hakemistorakennetta, niiden suositellusta koosta tarpeisiin nähden, millaisille tiedostoille ja ylipäätänsä millaiseen käyttöön. Se on vain turhaa. Teknisten dokumenttien tulkitsemista voimme jatkaa pilkuntarkkaan. Ainoa tulos on että niissäkään ei todeta suoraan että esimerkiksi Ext3 pirstaloituu niin herkästi että eheytystyökaluille on tarvetta. Sen sijaan todetaan että tietyissä tilanteissa, joissa jotakin tapahtuu, voidaan sen vaikutusta vähentää tekniikalla X. Mitään mustavalkoista sääntöä siitä ei löydy vaan oikeat tapahtumat määräävät sitä mikä oikeasti on tarpeellista ja mikä ei.
Ext3-tiedostojärjestelmä on laajasti käytetty sen ominaisuuksien vuoksi. Jos se olisi huono, kilpailevia tiedostojärjestelmiä olisi käytetty sen sijasta. Nyt sen sijaan tekniikka kun kehittyy, tiedostomäärät kasvavat ja vaaditaan uusia ominaisuuksia, Ext3n ominaisuudet jäävät vanhoiksi ja tarvitaan tuleviin tarpeisiin riittäviä tekniikoita, sitä varten Ext4 tiedostoformaattia lähdettiin kehittämään alunperinkin.
Ext3 has been a very popular Linux filesystem due to its
reliability, rich feature set, relatively good performance,
and strong compatibility between versions. The conser-
vative design of ext3 has given it the reputation of being
stable and robust, but has also limited its ability to scale
and perform well on large configurations.
Tärkeintä on että kun on mahdollisuus ja etenkin tarve parannella jotakin, niin tehdään eikä jäädä odottamaan.
Tiedostojärjestelmän pirstaloituminen ja tiedostojärjestelmän eheyttämisen tarpeellisuudesta keskusteleminen on kuin keskustelua veteen piirretystä rajaviivasta.
Tietyissä tilanteissa tarvetta voi esiintyä, mutta ei kaikissa. Ei ole yhtä sääntöä siihen. Windows-systeemejä käyttävät kuulevat liian usein neuvoja, että tiedostojärjestelmä pitäisi eheyttää kerran kuukaudessa tai kerran vuodessa tai ei koskaan koska NTFS ei pirstaloidu. Samalla tavalla on väärin sanoa suoraan että jokin Linux-käyttiksen tiedostojärjestelmä ei pirstaloidu, sitä kun tapahtuu kaikilla. Siitä voidaan keskustella, tarvitseeko eheyttämistä työpöytäkoneissa kuten joissakin tietyissä palvelinympäristöillä? Minun omat kokemukset, sadoista työasemista ja kymmenistä palvelimista. Kertoo että Ext3:sta ei tarvitse eheyttää kuin vain tietyissä tapauksissa ja pääsääntöisesti nekin ovat kaikki vain palvelimissa tapahtuvillle. Asiat muuttuvat niin työpöytäkäytössäkin jos joku päästää tiedostojärjestelmän liian täyteen tai käsittelee hyvin paljon eri kokoisia tiedostoja tietyllä tavalla. Tuolloinkin harvoin tullut tapaus vastaan että eheytys on ollut tarpeen ja silloinkin, riittänyt kun tehtyä kopiointi tai offline eheytys hitaasti. Samanlaisia ongelmia ei ole ollut kuin NTFS tai peräti FAT32 (tai vanhemmilla!) -tiedostojärjestelmillä.
Liian usein myös tullut seurattua peräti AMK-tason IT-koulutusta käyttöjärjestelmistä, joissa tuskin mainitaan edes tiedostojärjestelmien toimintaa ja rakennetta. Sitten jää paljon mielikuvia että jokin NTFS tai vastaava tiedostojärjestelmä ei tarvitse koskaan eheytystyökaluja koska se ei pirstaloidu. Tai sitten tietyissä tapauksissa kokemukset ovat jotain jolloin se ajatusmalli on 1/0. Välillä ei olisi mitään sellaista osuutta, että tiedostojärjestelmä pirstaloituu vähän, mutta sitä ei tarvitse eheyttää koska se ei pirstaloidu niin pahasti.
Jos minulla tulisi seuraavan viikon aikana 100 erilaista tapausta, joissa tiedostojärjestelmänä on Ext3. Ja jokainen näistä tapauksista olisi niin erinomaisessa kunnossa pirstaloitumisen osalta, että eheytystyökaluja ei tarvita. Miksi minun täytyisi alkaa kyselemään tai peräti ohjelmoimaan eheytystyökaluja jos niitä ei tarvita? Mitä sitten jos 1 tapaus noista sadasta olisi sellaisessa kunnossa että eheytys on tarpeen, onko silloin syitä alkaa kyselemään ja ohjelmoimaan? Jos tapauksia olisi aina 20% että eheyts olisi tarpeen, niin tuolloin alkaisin jo vaatimaan niitä työkaluja. Mutta tähän asti kun tapaukset ovat yhden prosentin luokkaa ja ongelma voidaan korjata muilla tavoin, ei minulla tule yhtäkään syytä vaatia ja etsiä eheytystyökaluja Ext3-tiedostojärjestelmää varten.
Ext-tiedostojärjestelmän neljäsversio, Ext4, tuo paljon parannuksia. Niitä tuskin kukaan voi kieltää että ne eivät ole tarpeellisia. Mutta tavalliselle kotikäyttäjälle valtaosa on sama kuin myisi mummolle ferrarin jolla kulkee sunnuntaisin 5km matkan kirkkoon ja takaisin tavallista maantietä pitkin.
Tiedostojärjestelmien kehittymisestä on kiva keskustella, tapahtuuhan se käyttöjärjestelmässä. Uusien tiedostojärjestelmien odottaminen on mukavaa kun saa lyödä vetoa mikä Linux-käyttiksen versio tuo seuraavan version mukanaan. Ehkä 2.8.32 versio tuo mukanaa "butter-filesystem" (btrfs) joka on tarpeen peruskäytössä.
-
Tuo erillisen /boot-osion tarve on minustakin kyllä aika paha puute. Tällä hetkellä tässä koneella on kuusi eri Linux-jakelua, joten jos jokaiselle joutuu vielä oman /boot-osion tekemään, rupeaa tulemaan kernelin 15 osion/laite -raja vastaan. LVM:ltakaan ei voi bootata, joten sinnekään niitä boot-osioita ei voi kätevästi lakaista. Lisäksi osioimisesta tulee tarpeettoman sekavaa.
Ihan joka koneessa ei toki välttämättä kuutta distroa ole asennettuna. :)
-
PS. Tietenkin siinä vaiheessa, kun GRUB-ongelma on ratkaistu helppoon lopputulokseen johtavasti, otan itsekin käyttöön ext4-järjestelmän.
No, nyt näyttäisi, että Jauntyn GRUB:iin on juuri tullut tuki boottaukselle ext4-osiolta.
grub (0.97-29ubuntu47) jaunty; urgency=low
[ Colin King ]
* New patch, ext4_support now allows grub to boot from ext4 partitions.
This patch orginated from Quentin Godfroy <godfroy@clipper.ens.fr>
Date: Tue, 06 Jan 2009 17:24:26 +0000
Changed-By: Tim Gardner <tim.gardner@canonical.com>
Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
https://launchpad.net/ubuntu/jaunty/....97-29ubuntu47
http://ubuntuforums.org/showthread.php?t=1033163 (http://ubuntuforums.org/showthread.php?t=1033163)
-
Ext3 pirstaloitumiskeskustelu on nyt kovinkin teoreettista, mutta on toki mielenkiintoinen aihe. Esimerkiksi Ux64 on sitä mieltä että pirstaloituminen on ongelma, kun taas Fri13 toista mieltä. Sinällään kun itsellä ei ole tietotaitoa, niin ei osaa mitään asiaan sanoa..
Mutta minusta tässä puuttuu konkreettiset testailut eli todistukset siitä kuinka paljon tuota pirstaloitumista tapahtuu? Esimerkiksi kun pidetään pitkiä aikoja n. 30-70% levyä täynnä, kuinka paljon se on pirstaloitunut normikäytössä? Entäs lähes täynnä oleva levy monen vuoden jälkeen? Nämä vain esimerkkinä, mutta siis testituloksia kaipaisin todisteeksi, niin nähtäisiin miten sitä pirstaloitumista tapahtuu :). Tietenkin vaikea tuollaista nyt on lähteä todistamaan omin testailuin (monta vuotta :)), mutta siis löytyykö jostain netin syövereistä testituloksia?
-
Ext3 pirstaloitumiskeskustelu on nyt kovinkin teoreettista, mutta on toki mielenkiintoinen aihe. Esimerkiksi Ux64 on sitä mieltä että pirstaloituminen on ongelma, kun taas Fri13 toista mieltä. Sinällään kun itsellä ei ole tietotaitoa, niin ei osaa mitään asiaan sanoa..
Tuota en ole määritellyt lainkaan onko se ongelma vai ei. Olen pyrkinyt juuri välttämään sitä ja pysymään teoreettisella tasolla. Olen siis todennut, että fragmentoitumista syntyy ja teoriassa kun sitä syntyy, eikä se poistu, niin sen pitäisi ajanmyötä pahentua ainakin teoriassa. Lisäksi ilmeisesti olin kirjoittanut jossain vaiheessa hyvin sekavasti. Kohdassa jossa viittasin siihen että sovellukset eivät sitä (pre-allokointia) osaa käyttää, lieni sen verran epäselvyyttä että monet ajattelivat että se koskisi delayed allokointia. Se kuinka suuria data kokonaisuuksia delayed allokoinnilla voidaan kerätä, on sitten toinen kysymys.
Mutta minusta tässä puuttuu konkreettiset testailut eli todistukset siitä kuinka paljon tuota pirstaloitumista tapahtuu?
Toinen kysymys on juuri se olennaisempi. Kun sitä tapahtuu, mikä on sen luonne ja onko siitä mitään haittaa. Esimerkiksi minulla on store osio, joka on tälläkin hetkelä 95% täynnä ja kun sinne 25 gigan vapaaseen tilaan kopioi esim 4 gigan tiedoston, niin se aivan tatusti fragmentoituu. Mutta toisaalta, eipä ole vielä koskaan HD videonkaan toisto tökkinyt sen takia, että data olisi liian fragmentoitunutta kiintolevyllä. Näin ollen store osiolla fragmentoituminen ei ainakaan ole ongelma. Lisäksi meillä (työ) on tuhansia työasemia kentällä, joissa on NTFS eikä niille ole koskaan tehty defragia, eikä kukaan ole vielä valittanut että kone ei sen takia toimisi. -> Sekään siis ei ole ongelma ainakaan meidän tuotantoympäristössä. Joillain palvelimilla huomattiin kyllä suorituskyvyn parantumista, koska levyllä oli satojatuhansia pieniä tiedostoja ja sittemmin hitaasti kasvaneita tietokantoja. Levy oli välillä hyvin täynnä ja aina noita pieniä tiedostoja siivottiin pois. Joten tietokanta oli äärimmäisen fragmentoinut. Onko se ongelma? Eipä oikeastaan, koska yleensä tuosta kannasta luetaan tietoa kuitenkin hajasaannilla sieltä täältä ja koneessa on 4 gigaa muistia, joten paljon suurempi merkitys on riittävällä muistilla kuin fragmentoitumisella. Defragin jälkeen todettiin että bootin jälkeen käynnistys ja sovellusten latautuminen on nopeampaa. Koneella on kuitenkin yksi sheduloitu bootti kuukaudessa sunnuntaina aamuyöstä. Onko sillä väliä boottaako kone kolmessa vai viidessä minuutissa. Eipä oikeastaan.
Esimerkiksi kun pidetään pitkiä aikoja n. 30-70% levyä täynnä, kuinka paljon se on pirstaloitunut normikäytössä? Entäs lähes täynnä oleva levy monen vuoden jälkeen? Nämä vain esimerkkinä, mutta siis testituloksia kaipaisin todisteeksi, niin nähtäisiin miten sitä pirstaloitumista tapahtuu :). Tietenkin vaikea tuollaista nyt on lähteä todistamaan omin testailuin (monta vuotta :)), mutta siis löytyykö jostain netin syövereistä testituloksia?
Kyllä sitä tapahtuu, tässä on mainittu työkaluista joilla voit sen todeta. Suurempi kysymys onkin se, mikä sen käytännönmerkitys on. Siksi tämä keskustelu onkin niin ympäripyöreää. Ihan kuten jonkun aspartaamin haittavaikutukset. Jos juotuaan pullon Pepsi Maxia kuolisi seuraavana päivänä, olisi se selvästi haitallista. Nyt kuitenkin ihmiset juovat tuota tököttiä vuosikausia ja kuolevat todennäköisesti vanhuuteen. Mikä oli siis aspartaamin osuus ongelmassa, jos sitä oli lainkaan? Tai sitten ilmastonlämpeneminen.... ;) Tutkijoita on laumoittain ja silti ei ole täysin vedenpitäviä esityksiä asiasta ja ristiriitaa riittää.
-
No, nyt näyttäisi, että Jauntyn GRUB:iin on juuri tullut tuki boottaukselle ext4-osiolta.
Ja uusimmassa (9.1.2009) "daily build" -versiossa pitäisi olla mukana Gparted, joka kykenee formatoimaan osion ext4-muotoon.
Luulenpa, että uusi puhdas asennus on ainoa oikea tapa korjata Jaunty ext4-pohjalle.
Ja siis koskien myös root-osiota. Erillistä boot-osiota ei tarvita.
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-January/006641.html (https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-January/006641.html)
Niin tuo linkki tuonne Ubuntun ISO-levykuvien "daily build" -sivustolle on ohessa:
http://cdimage.ubuntu.com/daily-live/ (http://cdimage.ubuntu.com/daily-live/)
-
"Daily buildilla" (live-cd) ei pysty asentamaan ext4:lle, koska siinä on edelleen bugi, joka sallii vain automaattisen osioinnin. Osioidessa manuaalisesti kyllä on valittavissa ext4, mutta siihen se jämähtää edelleenkin. Tämänpäiväisessä dailyssa ei Gpartedissa ole ext4 edes valittavissa. Täytyy kokeilla alternatea, miten se toimii: http://cdimage.ubuntu.com/daily/current/
EDIT: Alternate-tikulta asennus toimi ilman ongelmia (vanhan /-partition päälle) ja ainakin fstab näyttää nyt ext4:sta. Ja Gparted unknown, eli lienee oikein. 8)
-
EDIT: Alternate-tikulta asennus toimi ilman ongelmia (vanhan /-partition päälle) ja ainakin fstab näyttää nyt ext4:sta. Ja Gparted unknown, eli lienee oikein.
Juuri näin salai.
LiveUSB ei toimi, mutta alternate toimii.
Tein jo tuollaisen puhtaan asennuksen ykköskoneelleni (ext4 root ja home, 64-bit).
-
Minulla onnistui ext4:ksi asentaminen live-CD:ltä; asentamisen jälkeen joutui kyllä suorittamaan paikko-käskyn: fsck -pf /dev/osio.
Mutta mitä merkitsee ext4:n tulo ? Onhan ext3:n korvaavalla tiedostojärjestelmällä tajuton kiire. Mutta pahoin pelkään että ext4:n tulo merkitsee sitä ettei btrfs:ää nähdä ihan kohta.
-
Minulla onnistui ext4:ksi asentaminen live-CD:ltä; asentamisen jälkeen joutui kyllä suorittamaan paikko-käskyn: fsck -pf /dev/osio.
Mutta mitä merkitsee ext4:n tulo ? Onhan ext3:n korvaavalla tiedostojärjestelmällä tajuton kiire. Mutta pahoin pelkään että ext4:n tulo merkitsee sitä ettei btrfs:ää nähdä ihan kohta.
Kerrotko tarkemmin, miten tuo onnistui.
Live kyllä tarjoaa ext4-vaihtoehdon, mutta tekee siitä huolimatta ext3:n.
-
En enää muista tarkalleen. Pidin kyllä kokoajan asennus-päiväkirjaa, mutta se tuhoutui ext4:n osalta seuraavissa taistoissa omaa hölmöyttäni. Toiminta ext4:n asentamisessa oli jotenkin seuraavankaltainen: osion tekeminen etukäteen muotoon ext3 → asennuksessa: osioi itse → Ext4 tapahtumakirjanpidon sisältämä tiedostojärjestelmä → liitoskohta: / → asennus loppuun, päätteessä käsky: fsck -pf /dev/osio ja boottaus perään. Sitten /etc/fstabiin muutos käsin: ext3 → ext4 ja boottaus perään.
Siis pitkä taisto. On täysin hämärää kuinka tarkistin että tulos on tosiaan ext4 . Ainakin Gparted ja paljon muutakin sellaista puuttuu mitä pitäisikin puuttua, joku ohjelmakin kertoi muodoksi ext4, sudo e2fsck -f /dev/sda10 on nopea, isojen tiedostojen käsittely ...
-
En enää muista tarkalleen. Pidin kyllä kokoajan asennus-päiväkirjaa, mutta se tuhoutui ext4:n osalta seuraavissa taistoissa omaa hölmöyttäni. Toiminta ext4:n asentamisessa oli jotenkin seuraavankaltainen: osion tekeminen etukäteen muotoon ext3 → asennuksessa: osioi itse → Ext4 tapahtumakirjanpidon sisältämä tiedostojärjestelmä → liitoskohta: / → asennus loppuun, päätteessä käsky: fsck -pf /dev/osio ja boottaus perään. Sitten /etc/fstabiin muutos käsin: ext3 → ext4 ja boottaus perään.
Niin tässä siis järjestelmä asennettiin liveCD:ltä ext3:ksi.
Sitten asennuksen jälkeen muutettiin päätteeltä unmountatut osiot ext4-muotoon.
Tällä tavoin järjestelmä, josta tuo päätteen komento annetaan (mountattu) ei tietenkään muutu ext3:sta mihinkään.
Näissä on kyllä hiukan se ongelma, että osiolla olevat tiedostot eivät muutu extent-muotoon tallennetuksi.
Siinä pitää ne muuttaa sitten erikseen.
Varmaan on kokonaisuutena helpompi ja eheämpi tapa siirtää tärkeät tiedostot varmuuskopioina talteen ja asentaa järjestelmä uusiksi formatoimalla suoraan ext4-muotoon.
Näin kannattaa menetellä vähintäänkin root- ja home-osioiden suhteen.
Asennuksen jälkeen voi toki unmountattavissa olevat osiot formatoida erikseen.
Tämäkään ei tällä hetkellä suju GPartedilla, joka ei tunnista ext4:ää.
-
Tällä tavoin järjestelmä, josta tuo päätteen komento annetaan (mountattu) ei tietenkään muutu ext3:sta mihinkään.
Jos ymmärsin oikein, niin ajamalla ext4:n defrag ohjelman saa samalla muunnettua ext3 tiedostot ext4 muotoon. En sitten tiedä onko tuon kanssa vielä jotain ongelmia, mutta noin sen piti dokumentoinnin mukaan mennä. ;) Hauskintahan tuossa on se, että ext4 osiolla voi olla sekaisin "ext3" ja "ext4" muotoisia tiedostoja, ellei tuota konversiota defragin avulla tehdä. Tuollaiset ratkaisut on mielestäni joskus oikein käteviä tietylle tekniselle piirille, mutta yleisellä tasolla taas vastustan niitä kun ne lisäävät järjestelmän monimutkaisuutta lisäämällä useita erilaisia toteutusvaihtoehtoja samalle asialle.
Testipalstoilta poimittua.
· Ubuntu 9.04 Alpha (Build 20090112.1) with EXT3 filesystem boots in 24.5 seconds (on the Intel Core 2 Duo system);
· Ubuntu 9.04 Alpha (Build 20090112.1) with EXT4 filesystem boots in 21.4 seconds (on the Intel Core 2 Duo system)!
Ainakin jotain eroa siis on havaittavissa.
Asiaa sivuavia juttuja samaan viestiin, joita ei tarvitse kommentoida. Mutta on vaan FYI muodossa.
Vistan Defrag muuten pyrkii kokoamaan dataa vain 64 megan segmentteihin. Eli jos 640 megan tiedosto on 10 eri fragmentissa niin defrag ei kokoa sitä silti yhtenäiseksi.
BtrFS Wiki http://btrfs.wiki.kernel.org/index.php/Main_Page - BtrFS muuten muistuttaa tietorakenteiltaan hyvin paljon NTFSää. Kun taas Ext3 muistuttaa enemmän vanhempia ja perinteisempiä ratkaisuita. Vaikka Ext4 nyt sitä mielestäni olennaisesti parantaa.
Btw. Tein pienen testin NTFS levyllä (Vista käyttiksenä)
w pre-allocation 8 fragmented files, 89 frags
w/o pre-allocation 200 fragmented files, 2152 frags
Total file count 1726, total size 800 MBytes.
Auttoiko pre-allokointi vai eikö? Hmm, mielestäni se auttoi olennaisesti.
Tässä vielä yksi esimerkki jossa levylle on luotu ~200 megatavuinen tiedosto ilman pre-allokointia.
http://www.aijaa.com/v.php?i=3375592.png
Tilaa olisi ollut pistää tiedosto aivan yhtenäiseksi levylle vaikka kuinka moneen paikkaan, mutta näin ei ole kuitenkaan tapahtunut. Punaisella on siis merkitty kyseisen tiedoston hajonta pitkin levyä.
-
Jos ymmärsin oikein, niin ajamalla ext4:n defrag ohjelman saa samalla muunnettua ext3 tiedostot ext4 muotoon. En sitten tiedä onko tuon kanssa vielä jotain ongelmia, mutta noin sen piti dokumentoinnin mukaan mennä. ;)
Kyllä se noin menee, jos on kiintolevy on muutettu ext4:ksi entiset ext3-muotoiset tiedostot paikoillaan.
-
Tänäänkin tuli (ja eilen) päivitykset parted ja libparted (versioksi 1.8.8).
Mutta edelleenkään Gparted (v. 0.3.9-3.ubuntu1) ei ole päivittynyt tunnistamaan ext4-tiedostomuotoa.
Puhumattakaan siitä, että kykenisi sellaista osioimaan.
Ilmoittaa vain kylmästi "unknown".
-
Mitäs toimenpiteitä vaaditaan ext3:n muuttamisessa ext4:ksi, jos se on / ?
grubin uudelleenasennus?
-
Mitäs toimenpiteitä vaaditaan ext3:n muuttamisessa ext4:ksi, jos se on / ?
grubin uudelleenasennus?
Eikös helpointa olisi tehdä itselle iso-levykuja (daily-build) Jauntysta, ja nimenomaan se alternate-versio.
Sitten vaan uusi asennus root-osiolle, jolloin voidaan valita ext4-tiedostomuoto.
Grubin teko tulee siinä automaattisesti asennuksen lopussa.
Itse tein samalla uuden ext4-home-osionkin, jota ennen olin ottanut ylimääräiselle osiolle varmuuskopiot.
Varmuuskopio-osio jai ext3-muotoon.
Vielä tällä hetkellä Gparted ei pysty ext4:ään.
-
Mitäs toimenpiteitä vaaditaan ext3:n muuttamisessa ext4:ksi, jos se on / ?
grubin uudelleenasennus?
Eikös helpointa olisi tehdä itselle iso-levykuja (daily-build) Jauntysta, ja nimenomaan se alternate-versio.
Sitten vaan uusi asennus root-osiolle, jolloin voidaan valita ext4-tiedostomuoto.
Grubin teko tulee siinä automaattisesti asennuksen lopussa.
Itse tein samalla uuden ext4-home-osionkin, jota ennen olin ottanut ylimääräiselle osiolle varmuuskopiot.
Varmuuskopio-osio jai ext3-muotoon.
Vielä tällä hetkellä Gparted ei pysty ext4:ään.
Eikö kukaan ole kokeillut tune2fs:ää, livelevyllä se kuitenkin pitäisi tehdä sillä osio ei voi olla liitettynä.
Ja helpompi se olisi saman tien asentaa uusiksi, kuten harrykaa sanoi.
Itse asensi tänään normaali alpha3 levykuvasta, juuren ja kotikansion ext4 muotoon, hyvin luonnistui.
-
no ite oon niin lukuisia tunteja säätänyt ja viilannut tuota että täysi uudelleenasennus ei ole vaihtoehto.
-
no ite oon niin lukuisia tunteja säätänyt ja viilannut tuota että täysi uudelleenasennus ei ole vaihtoehto.
Voithan toki tehdä toimivan kompromissin, koska itse distro ei tässä vaihdu, eli kaikki asetukset toimivat edelleen.
Siis,
ota varmuuskopiona talteen koko Home-osion sisältö (myös piilotetut .xxx -kansiot).
Sitten alternatella teet uudelleenasennuksena formatoimalla ext4-osiot: root ja home.
Reboot ja siirrät omalle tilille kirjautuneena nautiluksella (ei sudo) varmuuskopioidut kansiot takaisin.
Ainakin suurin osa säädöistä tällöin palautuu.
Jos on mahdollista vaikkapa osioida ylimääräinen varmuuskopio-osio nykyisella ext3:lla, niin kansioiden siirtokaan ei ole iso operaatio.
Minä tein tämän siten, että tein pääkäyttäjänä varmuuskopio-osiolle "Backup"-hakemiston, ja muutin käyttöoikeudet omalle tililleni.
Tällöin sinne omalle tilille kirjautuneena pystyi siirtämään omat kansiot käyttöoikeudet automaattisesti säilyttäen.
Tuossa ext4-uudelleenasennuksessa en tietenkään tehnyt varmuuskopio-osiolle mitään.
-
http://ubuntuforums.org/showthread.php?t=1033163
noilla ohjeilla tein homman :D
ihmettelen vain että miksihän fstab on tyhjä..? (toimii kuitenkin hienosti)
virtanapin painaminen -> työpöydä ladattu -boottiaika lyheni n. 3 sekuntia :-) (kohta ollaan 20 sekunnin alapuolella..)
-
http://ubuntuforums.org/showthread.php?t=1033163
noilla ohjeilla tein homman :D
ihmettelen vain että miksihän fstab on tyhjä..? (toimii kuitenkin hienosti)
Teitkö siis noiden ohjeiden mukaan?
Siinähän nimenomaan pitää fstabiin korjata viittaus ext3:een viittaukseksi ext4:ään, ja joka osiolla.
-
http://ubuntuforums.org/showthread.php?t=1033163
noilla ohjeilla tein homman :D
ihmettelen vain että miksihän fstab on tyhjä..? (toimii kuitenkin hienosti)
Teitkö siis noiden ohjeiden mukaan?
Siinähän nimenomaan pitää fstabiin korjata viittaus ext3:een viittaukseksi ext4:ään, ja joka osiolla.
no sen kohdan skippasin tietenkin, kun koko fstab oli tyhjä.
-
no sen kohdan skippasin tietenkin, kun koko fstab oli tyhjä.
Ja siis Ubuntusi käynnistyy OK, vaikka juuri fstab sisältää tiedot käynnistyksessä liitettävistä osioista ja niiden asetuksista?
-
no sen kohdan skippasin tietenkin, kun koko fstab oli tyhjä.
Ja siis Ubuntusi käynnistyy OK, vaikka juuri fstab sisältää tiedot käynnistyksessä liitettävistä osioista ja niiden asetuksista?
Kyllä. Hyvin käynnistyy ::)
tekno@eee900:~$ di -h
Filesystem Mount Size Used Avail %Used fs Type
rootfs / 14.8G 12.8G 1.2G 92% rootfs
udev /dev 1008.6M 40.0k 1008.5M 0% tmpfs
tmpfs /dev/shm 1008.6M 0 1008.6M 0% tmpfs
tmpfs /lib/init/rw 1008.6M 0 1008.6M 0% tmpfs
varlock /var/lock 1008.6M 0 1008.6M 0% tmpfs
varrun /var/run 1008.6M 44.0k 1008.5M 0% tmpfs
tekno@eee900:~$ cat /etc/fstab
tekno@eee900:~$
-
Tietääkö joku kertoa, mistä tiedostosta näkyy (jos siis kerran /etc/fstab voi olla tyhjä) osioiden tiedostojärjestelmä (mm. ext3, ext4) tai missä ovat osioiden kirjoitussäännöt relatime, noatime ym?
Mm. nuo tiedothan annetaan asennuksen yhteydessä osioitaessa.
-
Tietääkö joku kertoa, mistä tiedostosta näkyy (jos siis kerran /etc/fstab voi olla tyhjä) osioiden tiedostojärjestelmä (mm. ext3, ext4) tai missä ovat osioiden kirjoitussäännöt relatime, noatime ym?
Mm. nuo tiedothan annetaan asennuksen yhteydessä osioitaessa.
mount -komennolla voi katsoa, mitä tiedostojärjestelmiä ja millä asetuksilla on ajohetkellä liitettynä.
-
mount -komennolla voi katsoa, mitä tiedostojärjestelmiä ja millä asetuksilla on ajohetkellä liitettynä.
Joo niin kyllä.
En esittänyt kysymystäni kyllin selvästi.
Mistä tiedostosta boottaava järjestelmä tuon katsoo, kun näyttää, että fstab sen ei tarvitse olla?
-
mount -komennolla voi katsoa, mitä tiedostojärjestelmiä ja millä asetuksilla on ajohetkellä liitettynä.
Joo niin kyllä.
En esittänyt kysymystäni kyllin selvästi.
Mistä tiedostosta boottaava järjestelmä tuon katsoo, kun näyttää, että fstab sen ei tarvitse olla?
Veikkaus on että udev tekee tuon?
-
Veikkaus on että udev tekee tuon?
OK.
Tässä muuten ihmettelen tätä ext4:ää koskevaa osaa Jauntyn esittelysivuilta:
http://www.ubuntu.com/testing/jaunty/alpha3 (http://www.ubuntu.com/testing/jaunty/alpha3).
"Ext4 installation support
Alpha 3 supports the option of installing on the new ext4 file system. Ext3 is likely to remain the default for Jaunty, and we will consider it as the default for Jaunty+1 based on user feedback."
Toisaalta ext4 tuntuu myös nopeuttavan boot-aikaa:
http://news.softpedia.com/news/Ubuntu-9-04-Boots-in-21-4-Seconds-101885.shtml (http://news.softpedia.com/news/Ubuntu-9-04-Boots-in-21-4-Seconds-101885.shtml)
"We've tested the boot process of a default Ubuntu 8.10 and 9.04 Alpha (Build 20090112.1) installation on two machines, an AMD Sempron 1.8 Ghz, 80 GB IDE hard drive with 512 RAM DDR and an Intel Core 2 Duo E4300 running at 2.2 Ghz, 250 GB SATA hard drive with 4 GB RAM DDR2. Here are the results of our tests:
· Ubuntu 8.10 with EXT3 filesystem boots in 31.8 seconds (on the AMD Sempron system);
· Ubuntu 9.04 Alpha (Build 20090112.1) with EXT3 filesystem boots in 28.3 seconds (on the AMD Sempron system);
· Ubuntu 9.04 Alpha (Build 20090112.1) with EXT4 filesystem boots in 23.1 seconds (on the AMD Sempron system).
· Ubuntu 8.10 with EXT3 filesystem boots in 26.8 seconds (on the Intel Core 2 Duo system);
· Ubuntu 9.04 Alpha (Build 20090112.1) with EXT3 filesystem boots in 24.5 seconds (on the Intel Core 2 Duo system);
· Ubuntu 9.04 Alpha (Build 20090112.1) with EXT4 filesystem boots in 21.4 seconds (on the Intel Core 2 Duo system)!"
-
Veikkaus on että udev tekee tuon?
OK.
Tässä muuten ihmettelen tätä ext4:ää koskevaa osaa Jauntyn esittelysivuilta:
http://www.ubuntu.com/testing/jaunty/alpha3 (http://www.ubuntu.com/testing/jaunty/alpha3).
Huom, kyseessä oli puhdas veikkaus, eli sen totuudenmukaisuutta sietää epäillä.
Toinen mahdollisuus on hal
Tuosta ihmettelystä ??
Siis miksi siitä ei tule oletusta vielä Jauntyssa?
Siihen vastaan että, kun kyseessä on kuitenkin vielä hieman keskeneräinen komponentti, josta pitää reunat hioa, ettei tule ikäviä yllätyksiä.
Jotkut käyttäjät ovat raportoineet datan menetyksiä, ja eihän sellaista saa sattua tuotantokoneilla...
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781
Jos keskustelu menee enemmän ubuntun puolelle tuossa ext4:ssa pyydän aloittamaan aiheen kehitysalueella... Jossa voi vapaammin keskustella ubuntun ja ext4 migraatiosta.
-
Joo. Alkoi pukkaamaan I/O erroria tiedostojen kohdalla. Piti ajaa vähän väliä fsck ja poistaa lisäksi käsin rikkoutuneet tiedostot jotta mm. apt-get suostui tekemään mitään. Nyt ei edes käynnisty koko systeemi. Alkunsa ongelmat saivat siitä kun virrat katkaistiin boottiprosessin aikana.
-
Jotkut käyttäjät ovat raportoineet datan menetyksiä, ja eihän sellaista saa sattua tuotantokoneilla...
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781
Jos keskustelu menee enemmän ubuntun puolelle tuossa ext4:ssa pyydän aloittamaan aiheen kehitysalueella... Jossa voi vapaammin keskustella ubuntun ja ext4 migraatiosta.
Ei ole Ext4 vika vaan ohjelmissa. Ext4 toimii juuri kuten kaikki uusimmat tiedostojärjestelmät. Tämä samainen tietojen häviäminen on mahollista nii NTFS, XFS ja monilla muilla tiedostojärjestelmillä.
Sitä voi vapaasti käyttää Ext4 mutta täytyy olla varma ettei 45-150 sekunnin välillä katkaise sähköjä tietokoneesta kun tietoja ei ole vielä muistista tallennettu levylle.
Tämän takia Ext4 onkin juuri nopeampi kuin Ext3 kun kirjoitus on viivästetty 5 sekunnin sijasta paljon pidemmälle, jolloi Linux käyttis pystyy suorittamaan muita tärkeämpiä levyoperaatioita ja tarkistamaan missä on tilaa ja tällä tavoin valvomaan koko operaation ja sitten kun aikaa ja tilaa on nii kirjoittamaan tiedot pysyvästi levylle. Nyt vain softat eivät kysy varmennusta että onko tieto kirjoitettu levylle vai ei, vaan olettavat että se on varmennettu vaikka ei olekkaan kun ei sync() ole kutsuttu softalta käyttikselle. vaihtoehtoisesti voi kyllä liittää kaikki tiedostojärjestelmät -async optiolla jolloi kaikki kirjoitus/luku operaatiot synkronoidaan ja se on varmaa kirjoitusta mutta varautukaa siihen että levytoiminta on sitten todella hidasta.
-
Muuta en voi sanoa kuin: hyvin on toiminut EXT4, ei minkäänlaisia ongelmia. Nopeakin on...
-
Muuta en voi sanoa kuin: hyvin on toiminut EXT4, ei minkäänlaisia ongelmia. Nopeakin on...
Kuulostaa hyvältä, ehkä tuon uskaltaa sitten JJ:n myötä ottaa käyttöön. Konversion kautta, jos toimii. Niin laiska ettei jaksa alusta asti ruveta työstämään.
-
Miten tuon ext4 saa asennettua? 9.04 perusversio haluaa asentaa ainakin automaattisesti tuon 3 version?
-
Miten tuon ext4 saa asennettua? 9.04 perusversio haluaa asentaa ainakin automaattisesti tuon 3 version?
Osioi itse kohdassa on mahdollista valita käyttöön.
-
JJ päivitetty, mutta jäin vielä tutkittuani asiaa miettimään paria pikkujuttua.
Kukaan konvertoinut vielä ext3 -> ext4? Ainakin virallisen wikin mukaan bootti ongelmia tulee jos bootin konvertoi ext4:ksi, joten olkoon tuo tekemättä.
Toinen asia on se, että ext3 -> ext4 konversio ei muuta vanhoja tiedostoja ext4 extents muotoon, vaan sitä varten pitää ajaa e4defrag, jotta käytännössä ruvetaan käyttämään uudempia datarakenteita.
-
Jooh, boottiongelmia tulee. Vanha GRUB ei osaa bootata EXT4-osiolta. Tähänkin on kai joku pätsi tehty vanhalle GRUB:lle, mutta se vaatisi, että GRUB käännetään uusiksi. GRUB2 osaa kyllä bootata, mutta ei taida tulla vakiona mukana Jauntyssa? Olen nyt itse tämän vuoden alusta käytellyt Archissa EXT4 ja minulla on seuraava osiointi (muistaakseni :D)
Eka osio: ~100MB EXT2 liitospisteellä "/boot" jotta GRUB toimii
Toka osio: ~10GB EXT4 liitospisteellä "/"
Kolmas osio: ~30GB EXT4 liitospisteellä "/home"
Konvertointia en ole kokeillut.
-
Kolmas osio: ~30GB EXT4 liitospisteellä "/home"
Konvertointia en ole kokeillut.
Konvertoin juuri data osion ext4:n, meni oikein hienosti.
Nyt pitäisi miettiä /boot konversiota, mutta kaikesta lukemastani päätellen taidan jättää sen tekemättä. Ei jaksa enää näin vanhana propellihattuna kaivaa verta nenästä ihan tahallaan.
ext4:ään vaihtaminen vaatii grubin päivittämisen käsin
Jos aiot päivittää ”/”- tai ”/boot”-tiedostojärjestelmäsi ext2:sta tai ext3:sta ext4:ään säilyttäen tiedot (kuten dokumentoitu ext4-wikissä), sinun täytyy myös käyttää ”grub-install”-komentoa Ubuntu 9.04:ään päivittämisen jälkeen asentaaksesi käynnistyslataimen uudelleen. Jos et tee tätä, käynnistyssektorille asennettu GRUB-versio ei osaa lukea ydintä ext4-tiedostojärjestelmästä ja järjestelmä ei käynnisty.
Tuo kyllä viittaa siihen että grubin päivittämisen jälkeen pitäisi toimia. Voisin oikeastaan ensin päivittää grubin ja sitten miettiä vielä asiaa.
Toinen ongelma joka tuli vastaan on se, että taas kerran nopeasti polttava cd-asema on tehnyt sellaista sutta, ettei tämän koneen asema lue levyä. Eli kun ei ole vara-bootti levyä jauntylle, en taida uskaltaa ruveta sössimään. Eikä / konversiota varmaan pysty tekemään mounttaamatta ja todnäk umount / ei taida toimia. (Joku viisaampi voisi valaista miten homma hoidetaan), jos ylipäätänsä on mahdollista.
Toisekseen oli mahdollista käytää ext4 "modea" ilman extents tilaa, jolloin monet ext4 ominaisuudet ovat käytössä, ilman extents tukea. Tuon voi käsittääkseni muuttaa suoraan mount-optioista käyttöön. (taas kerran mutua lukemani perusteella, vailla oikeaa tietoa).
*** jatkuu *** ext4 boot käytössä ja kone käynnissä ***
Poltin Ubuntu levyn uudelleen koneen omalla polttimella ja se toimi. Koska olin tehnyt jo GRUB-päivityksen aikaisemmin. Oli CD:ltä bootin jälkeen aika helppoa tehdä ext4 päivitys myös /dev/sda1 devicelle. Kaikki levyt siis hodettu migraation / konvertoinnin, eikä uudelleen formatoinnin kautta.
Kaikista negatiivisista odotuksistani huolimatta, kaikki toimii kuten pitää kun vaan luki ohjeet ja seurasi niitä.
Nyt siis levyn kirjanpito ja ajurit on ext4 ajassa. Ainoa ongelma on se, että levyllä jo oleva data EI ole ext4-ajassa. e4defrag sovelluksen pitäisi hoitaa tuo asia kuntoon. En kuitenkaan löydä sitä synapticista. Eli ilmeisesti sen osalta ei ole vielä valmista?
Pitänee tarrata fileet poistaa ne ja purkaa takaisin. Öh, legacy defrag-menetelmä, heh. Mutta tuon operaation pitäisi siis hyödyntää datalle uutta allokaattoria.
e4tools ja e4defrag paketteja odotellessa.
Kiroilen kyllä jos jotain menee metsään, mutta tähän asti kaikki näyttää oikein hyvältä.
*** Datan katoilusta ***
http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds--/news/112892
Menee juuri niin kuin odotinkin sen menevän. Kyseessä ei siis ole missään nimessä vika. Jos se olisi vika, voisi koko tiedostojärjestelmä räjähtää käsiin. Nyt vain osa datasta jäi puuttumaan.
Levyjärjestelmän korruptoituminen ei tarkoita sitä että pari viimeistä "kirjoitusta" katoaa, kuten raporteissa. Vaan sitä että kokonaiset hakemistorakenteet sekoaa, tiedostojen ja hakemistojen sisällöt on sekaisin jne. Tietokannoissa tuota tapahtuu silloin kun tietokannan kirjanpitotiedot sekoaa ja indeksit sekoaa. UUdelleen indeksointi voi toimia, mutta silloinkin menetetään joskus dataa jos myös tietokannan sisältö on korruptoitunut. Kyllä, tuota tapahtuu aina ajoittain. Silloin seuraava askel onkin se, että kuinka hyvä korjausrutiini tuolle on kehitetty. Tyyliin fat levyjen cross linking fix.
Miksi käytetään upseja, miksi järjestelmät kahdennetaan, miksi softissa on omat logit joiden pohjalta tehdään vielä data rollback jos jotain on kesken? Miksi järjestelmät toimivat rinnakkain koneissa joiden tulosten pitää olla samat?
alloc_on_commit optio "korjaa" tuon "ongelman". Koska molemmat ovat suhteellisia asiota. Henkilökohtaisesti vihaan em. toiminnallisuutta. Meillä tuotantojärjestelmät käsittlee esim valtavia määrtiä suhteellisen pieniä XML aineistoja. Jos käytetään alloc_on_committia, putoaa järjestelmän nopeus tuhannesosaan siitä mitä se on ilman tuota optiota. Koska nyt esimerkiksi 1000 luotua tiedostoa voidaan järjestää levylle muutamalla kirjoituksella, sen sijaan että kirjoiteaan levylle esim 8000 kertaa.
*** Ihan muuta horinaa ***
Joo, paljon pikkutiedostoja on hölmöä. Se on vielä hölmömpää FTP:n kanssa. Mutta minkäs voit, näin on joskus järjestelmä suunniteltu. Tietysti voisi korvata tuon FTP palvelimen "virtuaali ftp:llä" jossa data "tiedostot" luodaan lennossa tietokannan perusteela silloin kun niitä noudetaan. Mutta kovin on työläs vaihtoehto tuo.
Vielä parempi olisi jos kaikki integraatiot jotka käyttävät tuota teidonsiirtorajapintaa konvertoitaisiin käyttmään jotain uutta järkevämpää protokollaa. Joka siirtäisi datan esim 20-50 megan paloissa ja yhden TCP session kautta. Mutta vaatisi standardin FTP:n korvaamisen omalla softalla. Kun integraatioita on useille eri alustoille, sekään ei ole kovin järkevä vaihtoehto. Koska nykyinenkin ratkaisu toimii ja protokollan uusiminen maksaisi kymmeniätuhansia.
-
Kyllä tää ext4 on hiaano peli.
Aikaisemmin tässä säikeessä mukaillen lainatakseni, että prameeta on ajella lähikauppaan porshella.
Aivan 100 varma en ole, että JJ:ssä nopeutukseen olisi yksistään syyllinen ext4, kun en tätä järjestelmää ole kokeillut ext3:lla. FireFoxia pystyy nyt jopa käyttämään, vaikka ajoittaisia jäätymisiä vieläkin ilmenee, mutta ne eivät ole lähellekään niin pahoja kuin ext3+Hardyssä tai Ipexissä. Koneena siis on 901 eeePC, jossa 9.04:nen Ubuntu Ext4:lla hitaassa asemassa. Vielä en ole tallentanut tärkeitä tiedostoja ext4:seen, mutta katsotaan...
-
Kyllä tää ext4 on hiaano peli.
Aikaisemmin tässä säikeessä mukaillen lainatakseni, että prameeta on ajella lähikauppaan porshella.
Aivan 100 varma en ole, että JJ:ssä nopeutukseen olisi yksistään syyllinen ext4, kun en tätä järjestelmää ole kokeillut ext3:lla. FireFoxia pystyy nyt jopa käyttämään, vaikka ajoittaisia jäätymisiä vieläkin ilmenee, mutta ne eivät ole lähellekään niin pahoja kuin ext3+Hardyssä tai Ipexissä. Koneena siis on 901 eeePC, jossa 9.04:nen Ubuntu Ext4:lla hitaassa asemassa. Vielä en ole tallentanut tärkeitä tiedostoja ext4:seen, mutta katsotaan...
Päivitin muutama päivä sitten 901:ni Jauntyyn, mutta "fiksusti" laitoin ext2:n tiedostojärjestelmäksi sekä juureen että kotiosiolle. Pystyykö tuota nostamaan ext4:ään ilman formatointia?
-
Päivitin muutama päivä sitten 901:ni Jauntyyn, mutta "fiksusti" laitoin ext2:n tiedostojärjestelmäksi sekä juureen että kotiosiolle. Pystyykö tuota nostamaan ext4:ään ilman formatointia?
Pystyy. Ihan kuten sanoin tuossa. Ensin ext2 -> ext3 ja siitä ext3 -> ext4 ohjeen mukaan. Menee ihan kivuttomasti. fsck:n ajoon tosin pitää varata hieman aikaa.
-
Päivitin muutama päivä sitten 901:ni Jauntyyn, mutta "fiksusti" laitoin ext2:n tiedostojärjestelmäksi sekä juureen että kotiosiolle. Pystyykö tuota nostamaan ext4:ään ilman formatointia?
Pystyy. Ihan kuten sanoin tuossa. Ensin ext2 -> ext3 ja siitä ext3 -> ext4 ohjeen mukaan. Menee ihan kivuttomasti. fsck:n ajoon tosin pitää varata hieman aikaa.
Hoplaa! Sen siitä saa, kun ei tajua lukea kunnolla. Täytynee kokeilla, jos tuo auttaisi niin, ettei tarvitsisi kikkailla suuremmin ja saisi Firefoxin toimimaan jäätyilemättä. Aiemmin pistin tempit wikin ohjeen mukaan menemään keskusmuistiin, mutta sitten piti kikkailla, että sai Apachen lokivaroitukset pois. Palvelimella ei kuitenkaan mitään niin korvaamatonta ole, etteikö ext4 saisi sitä hävittää. Mutta ehkä kumminkin otan ensin varmuuskopiot ;)
-
Hoplaa! Sen siitä saa, kun ei tajua lukea kunnolla. Täytynee kokeilla, jos tuo auttaisi niin, ettei tarvitsisi kikkailla suuremmin ja saisi Firefoxin toimimaan jäätyilemättä.
Kyllä FF jäätyilee edelleenkin ext4:n asennuksen jälkeenkin, mutta enää se ei ole niin mahdotonta, etteikö sitä voisi käyttää.
Mutta käyttäjiä on moneksi, ja jokaisella on vähän omanlainen sietokynnys liiallisen jäätyilyn kanssa.
-
Saas muuten nähdä kauanko kestää ennen kuin ohjelmistot alkavat käyttää pre-allocationia jota ext4 tukee. ext3 kun ei sitä tukenut.
Tuo tulee vielä olennaisesti vähentämään fragmentoitumista. Se on itseasiassa ensimmäinen asia joka käytännössä estää fragmentoitumisen, mikäli yhtenäistä levytilaa ylipäätänsä löytyy tarpeeksi.
Samalla on jännä seurata sitä milloin e4defrag sovellus saadaan valmiiksi, koska ilman sitä ext3 -> ext4 konversiota ei saa vietyä loppuunasti.
-
Käytän Ubuntu 9.04 ja ext4:ää Kaikki toimii hyvin. Kone käynnistyy normaalisti, mutta Skype tule paljon nopeammin ylös. Koko kone saa kytketty pois päältä nopeasti non 10 sek. Kun klikkaa uutta dokumentia OpenOffice käynnistyy niin nopeasti (2 sek) ettei pitkä käynnistysaika enää häiritse. En tiedä onko se ext4 tai uudet ohjelmat, mutta kombinaatio Ubuntu 9.04 ja ext4 voin suositella. Olen kuullut että pian tulee uusi kernel. Silloin on hyvä että myös kaikki muut on paikalla. Kaikki vanhat kuvat ja textit ovat säilyneet.
-
Jokos tuota ext4:ää voi käyttää juuressa ilman erillistä ext3 /boottia? Jauntyllä tietenkin. Ajattelin vaan, että pitäisiköhän laittaa uuden kiintolevyn kanssa tuo ext4 käyttöön... :)
-
Jokos tuota ext4:ää voi käyttää juuressa ilman erillistä ext3 /boottia? Jauntyllä tietenkin. Ajattelin vaan, että pitäisiköhän laittaa uuden kiintolevyn kanssa tuo ext4 käyttöön... :)
grub (0.97-29ubuntu47) jaunty; urgency=low
[ Colin King ]
* New patch, ext4_support now allows grub to boot from ext4 partitions.
This patch orginated from Quentin Godfroy <godfroy@clipper.ens.fr>
-- Tim Gardner <tim.gardner@canonical.com> Tue, 06 Jan 2009 17:24:26 +0000
-
Jokos tuota ext4:ää voi käyttää juuressa ilman erillistä ext3 /boottia? Jauntyllä tietenkin. Ajattelin vaan, että pitäisiköhän laittaa uuden kiintolevyn kanssa tuo ext4 käyttöön... :)
grub (0.97-29ubuntu47) jaunty; urgency=low
[ Colin King ]
* New patch, ext4_support now allows grub to boot from ext4 partitions.
This patch orginated from Quentin Godfroy <godfroy@clipper.ens.fr>
-- Tim Gardner <tim.gardner@canonical.com> Tue, 06 Jan 2009 17:24:26 +0000
Eli onnistuu. Hyvä tietää. Kiitos. :)
-
En lukenut kaikkea kuutta sivua keskustelua, mutta muistuttaisin, että vakavan bugin takia ext4 järjestelmä saattaa kaatua ja tietoa saattaa hävitä. Aiheesta lisää:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/330824
-
En lukenut kaikkea kuutta sivua keskustelua, mutta muistuttaisin, että vakavan bugin takia ext4 järjestelmä saattaa kaatua ja tietoa saattaa hävitä. Aiheesta lisää:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/330824
Vaikuttaa ihan oikealta ongelmalta ja vialta, toisin kuin se horina että write cachessa oleva data voi kadota jos virrat katkaisee joka on aika itsestään selvyys.
Olen tässä juuri tuollaisten ongelma case fileiden kanssa työskennellytkin lähipäivinä. Reilu satatuhatta 1-30 kilon kokoista tiedostoa about, muutamassa hakemistossa. Ei mitään ongelmia, mutta käytössä onkin 64 bittinen kerneli. Eli ilmeisesti en sitten kuulu ongelma sektoriin sen takia. Uskoisin että sillä määrällä mitä olen noita tiedostoja käsitellyt ohjelmallisesesti ja erityisesti tuhonnut erilaisia temp fileitä miljoonia, niin olisin voinutkin törmätä ongelmaan.
Tietenkin ongelmien toistaminen jotka ilmene harvoin, vain tietyillä erikoisella kokoonpanolla tai asetuksilla niin spottaaminen voi olla hyvinkin haastavaa. Been there done that. Joskus ongelmien löytäminen kestää vuosia. Vaikka ne olisivatkin sitten aivan selviä kun vain täsmällinen toistamisprotokolla on saatu selville.
-
Vasta kun pengoin mount optioita, niin huomasin tämän:
commit=60
Eli ext3:ssa ainakin root systemillä oli fiksattu commit aika 5 sekkaa. Jota ei ilmeisesti ainakaan parametrinä pystynyt säätämään, patchillä ja uudelleen käätämisellä taas kyllä varmaan.
Mutta ext4:n kanssa commit aikaa voi säätää suoraan parametrinä. Tuo vaikuttaa siihen kuika paljon dataa voi olla jonossa levylle. Ei tosin selvinnyt mistään nopeasti, koskeeko tämä delayed allocationissa olevaa dataa vai ei. Saamani mielikuvan mukaan ei koske. Mutta voin olla myös väärässä siitä.
Slashdot: http://ask.slashdot.org/story/09/05/30/161233/Is-ext4-Stable-For-Production-Systems
P.S. fsck tuntui muuten vieläkin todella ärsyttävän hitaalta reilut 8 minsaa meni 250 gigasella kakkoslevyllä. ;(
-
Onkohan se tuo yllämainittu linkki bugiin kun muutaman kerran olen saanut tämän HP:n ihan nalkkiin kun olen antanut kopioitavaa oikein kunnolla Nautilukselle? Nämä on ollut tapauksia missä olen yleensä kopioinut isoja dvb tiedostoja ja saattanut antaa sen jälkeen useammat pienempien tiedostojen kopiointikäskyt erikseen esim. kuvia tms.
Olisi meinaan närästänyt kyllä pahasti jos olisin sattunut siirtämään tiedostoja, onneksi nämä on sattunut varmuuskopioinnissa ja vika tulee tosiaan todella selkeästi esiin :D
En tiedä onko tuo sitten ihan vain nautilus bugi vai mikä. Pitäisi kokeilla jossain välissä ihan mielenkiinnosta kopioida ilman X:ää saman tyylisiä tiedostoja. Yritin pikaisesti katsella myös lokeja, mutta kun en niistäkään mukaan oikein löytänyt mitään, mikä voi olla kyllä ihan täysin taidon puutetta.
Pitänee odottaa seuraavan kerran tuohon törmätessä pitempään jos törmäisi tuohon cpu erroriin.
*edit*
Joka tapauksessa tämä kunnon jäätyminen on tapahtunut kun konetta on kuormittanut reilusti poikkeavasta enemmän tiedonsiirroilla.
-
Nyt on alla EXT4, Jaunty ja kahden levyn raid-1 ja suht. hyvin toimii. Huomattavasti nopeampi, kuin mitä ext3. Netbeans aikaisemmin hidasteli kivasti, mutta nyt ei ongelmia. Myös OOffice ja muut lähtevät varsin sukkelasti käyntiin. Ainut ongelma, että kun transmissionilla aloittaa uuden .torrent latauksen, niin transmission vetää 99% tehoja ja kone lähes lukossa. Esimerkkinä, kun laitoin 30 gigan paketin valumaan, niin kone oli ehkä noin 5 min jäässä ;D
-
En tiedä mikä mätti, mutta kun käynnistin konetta niin tuli ensin RO mountti ja sitten seuraavalla bootilla tuli pakotettu fsck ja kolmannella vasta vehje lähti känytiin. Mutta toipumisprosessi meni sentään kuten piti.
Syystä tai toisesta kuitenkin ext4:lla on myös aika tuskaista työskennellä koneella jos on muuta levy i/o:ta. Eli juuri em. ongelman minimoiseksi uskoisin NCQ:n tms auttavan.
Tästä aiheesta siis lisää täällä:
http://forum.ubuntu-fi.org/index.php?topic=27993.msg214702
-
Muutin tänään kaikki levyjeni tiedostojärjestelmät ext4-muotoon. Olin lukenut vertailutuloksista (http://gmrpgsql.tumblr.com/post/73798984/initial-ext3-vs-ext4-results) ext3:n ja ext4:n välillä, mutta silti yllätyin siitä miten sulavalta uusi filesystem tuntuu. Pelkästään boottiaikakin nopeutui jopa 4 sekuntia, ja näkisin että tästä on yksinomaan kiittäminen ext4:ää.
Tiedostojen lukuaika on muutenkin selvästi rivakampi kuin ext3:ssa.
Suosittelen ext4:ään siirtymistä lämpimästi muillekin.
-
Muutin tänään kaikki levyjeni tiedostojärjestelmät ext4-muotoon. Olin lukenut vertailutuloksista (http://gmrpgsql.tumblr.com/post/73798984/initial-ext3-vs-ext4-results) ext3:n ja ext4:n välillä, mutta silti yllätyin siitä miten sulavalta uusi filesystem tuntuu. Pelkästään boottiaikakin nopeutui jopa 4 sekuntia, ja näkisin että tästä on yksinomaan kiittäminen ext4:ää.
Tiedostojen lukuaika on muutenkin selvästi rivakampi kuin ext3:ssa.
Suosittelen ext4:ään siirtymistä lämpimästi muillekin.
Haluaako joku kirjoittaa mummo-ohjeet olemassaolevan ext3 /-levyn (jossa siis myös boot-osio mukana) konvertoinniksi ext4:ksi niin, että myös olemassaolevat tiedostot ovat ext4:n mukaisia?
Vai riittääkö:
- cd-boot
- /:n mount jonnekin
- fstab:iin ext3 -> ext4
- /sbin/tune2fs -O extents,uninit_bg,dir_index mountatulle /-osiolle
- /sbin/e2fsck -fD mountatulle /-osiolle
?
-Petri
-
Taidat päästä kaikkein helpopimmalla kun/jos asennat uusiksi ja osioit käsin ext4-muotoon.
edit. katso tämän aiheen vastaus # 67 ;) http://forum.ubuntu-fi.org/index.php?topic=13776.msg182758#msg182758
-
Haluaako joku kirjoittaa mummo-ohjeet olemassaolevan ext3 /-levyn (jossa siis myös boot-osio mukana) konvertoinniksi ext4:ksi niin, että myös olemassaolevat tiedostot ovat ext4:n mukaisia?
Tein helpoimman ja varmimman tavan kautta, eli formatoin koko levyn ja alustin uudestaan ext4:ksi.
Toki se ei ole niin helppo tapa, jossei ole useampia fyysisiä levyjä, jonne siirtää tiedostojaan turvaan alustettavalta levyltä.
-
Kokeilin puhtaan asennuksen kautta ext4 tiedostojärjestelmää, mutta vaihdoin takasin ext3. Tällä kannettavalla aika ajoin ubuntu jäätyi täysin, eikä auttanut muu kuin virrat pois. Jäätymistä ilmeni eniten tiedostoja siirrettäessä.
-
Kokeilin puhtaan asennuksen kautta ext4 tiedostojärjestelmää, mutta vaihdoin takasin ext3. Tällä kannettavalla aika ajoin ubuntu jäätyi täysin, eikä auttanut muu kuin virrat pois. Jäätymistä ilmeni eniten tiedostoja siirrettäessä.
Mistähän tuo juontaa, koska mulla on ollut käytössä ext4 pitkään ja hartaasti, enkä ole tuollaiseen ongelmaan törmännyt lainkaan. Jotain vikaa jollain tasolla, mutta tietysti kovin vaikeaa sanoa missä. Ja varsinkin jos ainoa ero asennuksissa oli ext3 / ext4 ero.
-
Kokeilin puhtaan asennuksen kautta ext4 tiedostojärjestelmää, mutta vaihdoin takasin ext3. Tällä kannettavalla aika ajoin ubuntu jäätyi täysin, eikä auttanut muu kuin virrat pois. Jäätymistä ilmeni eniten tiedostoja siirrettäessä.
Mistähän tuo juontaa, koska mulla on ollut käytössä ext4 pitkään ja hartaasti, enkä ole tuollaiseen ongelmaan törmännyt lainkaan. Jotain vikaa jollain tasolla, mutta tietysti kovin vaikeaa sanoa missä. Ja varsinkin jos ainoa ero asennuksissa oli ext3 / ext4 ero.
Sama juttu ja ihmetyksen aihe. Aika monta asennusta tullut tehtyä monenlaisiin koneisiin ja ext4 eikä mitään ongelmia.
Mattu36: mitkä osiot laitoit muotoon EXT4 kun asensit ja miten teit osioinnin yleensäkin?
-
Sama juttu ja ihmetyksen aihe. Aika monta asennusta tullut tehtyä monenlaisiin koneisiin ja ext4 eikä mitään ongelmia.
Mattu36: mitkä osiot laitoit muotoon EXT4 kun asensit ja miten teit osioinnin yleensäkin?
Osioinnin tein Ubuntun asennus vaiheessa, osiointi-työkalulla. Ext4-osio oli se mihin Ubuntun asensin.
Kokeilin vain, että miten ext4 toimii, mutta hyvin ext3:lla pärjää. Kyseinen kannettava ei ole mitään uusinta mallia.
-
Ei lähtenyt taas tänä aamuna systeemi käyntiin ennen manuaalista fsck:ta ja tällasta puski.
Näyttäs toipuneen ainakin kohtuullisesti, nopeasti en löytänyt mitään korruptiota. Mutta huolettaa se että mikä tuon aiheutti ja tietysti se mitä tuosta olisi voinut seurata. On nimittäin ikäviä kokemuksia filesystemien sekoilusta ja piilokorruptoitumisesta.
Kommentteja otetaan mielellään vastaan ja onko muilla vastaavia kokemuksia.
Error: "Rezise inode not valid" ja sen perään vielä monta muuta mehevää virheilmoitusta.
(http://www.aijaa.com/img/t/00122/4605427.t.jpg) (http://www.aijaa.com/v.php?i=4605427.jpg)
-
Ux64: liittyykö ongelmasi (tai siis koneen ongelma) välttämättä EXT4:seen? Vaikka se oisi alkanut sen jälkeen kun vaihdoit EXT3 => EXT4....
-
Ux64: liittyykö ongelmasi (tai siis koneen ongelma) välttämättä EXT4:seen? Vaikka se oisi alkanut sen jälkeen kun vaihdoit EXT3 => EXT4....
Ei välttämättä, eikä ole myöskään ilmennyt tuon jälkeen. Yksi mahdollinen syy on se, että saatoin katkaista virran muutamia sekuntteja liian aikaisin shutdownin yhteydessä. Tuota sattuu aina ajoittain.
Tietysti asiallisen systeemin pitäisi selvitä tuosta sen kummemmitta ongelmitta / valituksitta.
Mutta e4defrag tilanne kiinnostaa edelleen? Onko kenellkään tietoa milloin pitäisi olla valmista? Vasta tuolla voi tehdä täyden konversion EXT3 => EXT4.
Lisättäköön että jos e4defrag on valmis, niin aloitetaan siitä sitten oma viestiketjunsa.
-
Ext4:n hyödyt tulevat ilmi ilmeisesti vain riittävän tehokkaassa koneessa, ja olisi kiva jos joku tekisi vertailutaulukot eri tehoisilla koneilla ext4:n ja ext3:n välillä.
Sellainen hauska tapaus omalta kohdalta, kun testikoneessani (1.6 Ghz prossu + 512 Mt ram) kokeilin openSUSEa ext4-tiedostojärjestelmällä, niin kaikki tuntui menevän aluksi hyvin, mutta jonkin ajan kuluttua kone alkoi hidastumaan hidastumistaan. Kun katsoin muistinkulutuksen, niin se oli lopulta yli 800Mt, ja kasvoi kiihtyvällä vauhdilla. Kone oli pakko sammuttaa virtakatkaisijasta, sillä se karkasi hallinnasta ;D
Todennäköisesti testikoneeni on hieman liian tehoton joko openSUSElle tai sitten ext4:ssä prosessit kasaantuivat liian suuriksi ???
Täytyy varmaan käyttää hieman tehokkaampaa konetta testikoneena.. :D
-
Sellainen hauska tapaus omalta kohdalta, kun testikoneessani (1.6 Ghz prossu + 512 Mt ram) kokeilin openSUSEa ext4-tiedostojärjestelmällä, niin kaikki tuntui menevän aluksi hyvin, mutta jonkin ajan kuluttua kone alkoi hidastumaan hidastumistaan. Kun katsoin muistinkulutuksen, niin se oli lopulta yli 800Mt, ja kasvoi kiihtyvällä vauhdilla. Kone oli pakko sammuttaa virtakatkaisijasta, sillä se karkasi hallinnasta ;D
Muistivuotobugi jossain ohjelmassa. Tuskin liittyy tiedostojärjestelmään.
-
Sellainen hauska tapaus omalta kohdalta, kun testikoneessani (1.6 Ghz prossu + 512 Mt ram) kokeilin openSUSEa ext4-tiedostojärjestelmällä, niin kaikki tuntui menevän aluksi hyvin, mutta jonkin ajan kuluttua kone alkoi hidastumaan hidastumistaan. Kun katsoin muistinkulutuksen, niin se oli lopulta yli 800Mt, ja kasvoi kiihtyvällä vauhdilla. Kone oli pakko sammuttaa virtakatkaisijasta, sillä se karkasi hallinnasta ;D
Muistivuotobugi jossain ohjelmassa. Tuskin liittyy tiedostojärjestelmään.
Jokin bugi ilmeisesti, mutta kuitenkin ext3 tiedostojärjestelmällä toimi ihan normaalisti. Ext4.ssä tieto viipyy kauemmin välimuistissa, joten tulkitsen sen olevan hieman ongelmallista tehottomassa koneessa. Huomasin erään toisenkin törmänneen vastaavankaltaiseen ongelmaan :o
Kokeilin puhtaan asennuksen kautta ext4 tiedostojärjestelmää, mutta vaihdoin takasin ext3. Tällä kannettavalla aika ajoin ubuntu jäätyi täysin, eikä auttanut muu kuin virrat pois. Jäätymistä ilmeni eniten tiedostoja siirrettäessä.
-
Ext4: Tässä taas yksi havainto: 8 gigan tiedosto. Kun sitä kasvatettiin pikkuhiljaa tilanne oli se että se oli 1352 palassa ja kun kopioin sen vaan uudelleen samalle volumille se on 73 palassa.
Taas yksi syy siihen, miksi tiedostot pitäisi aina pre-allokoida. Ja kuten aikaisemmin olen sanonut, NTFS:n puolella vaikutus pre-allokoinnilla tuntuu olevan vielä ainakin 10-100 kertaa suurempi.