Kirjoittaja Aihe: Ext4  (Luettu 51229 kertaa)

jake

  • Käyttäjä
  • Viestejä: 1262
    • Profiili
Vs: Ext4
« Vastaus #40 : 31.12.08 - klo:16.28 »
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... ;)
Kaikille avoin standardi antaa mahdollisuuden valita itselle sopivin ohjelmisto käyttöön.
Millään taholla ei ole oikeutta pakottaa muita käyttämään jotain tiettyä sovellusta tietojen vaihdossa.
"Valitsin siis avointa standardia noudattavat sovellukset, esim: OpenOffice, Firefox ja tiett

mgronber

  • Käyttäjä
  • Viestejä: 1458
    • Profiili
Vs: Ext4
« Vastaus #41 : 31.12.08 - klo:23.18 »
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.

Lainaus
Lainaus
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.

Lainaus
Lainaus
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.

Lainaus
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.

Lainaus
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?

Lainaus
Lainaus
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.

Lainaus
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.

Lainaus
Lainaus
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...

Senior

  • Vieras
Vs: Ext4
« Vastaus #42 : 01.01.09 - klo:07.26 »
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.

Fri13

  • Käyttäjä
  • Viestejä: 465
    • Profiili
Vs: Ext4
« Vastaus #43 : 01.01.09 - klo:12.15 »
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?


Lainaus
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ä.

Ux64

  • Käyttäjä
  • Viestejä: 586
    • Profiili
Vs: Ext4
« Vastaus #44 : 02.01.09 - klo:08.38 »
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.
« Viimeksi muokattu: 02.01.09 - klo:08.49 kirjoittanut Ux64 »

mgronber

  • Käyttäjä
  • Viestejä: 1458
    • Profiili
Vs: Ext4
« Vastaus #45 : 02.01.09 - klo:15.53 »
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?

Ux64

  • Käyttäjä
  • Viestejä: 586
    • Profiili
Vs: Ext4
« Vastaus #46 : 02.01.09 - klo:17.20 »
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.

« Viimeksi muokattu: 03.01.09 - klo:13.40 kirjoittanut Ux64 »

Ux64

  • Käyttäjä
  • Viestejä: 586
    • Profiili
Vs: Ext4
« Vastaus #47 : 03.01.09 - klo:14.03 »
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.
« Viimeksi muokattu: 03.01.09 - klo:15.06 kirjoittanut Ux64 »

harrykaa

  • Vieras
Vs: Ext4
« Vastaus #48 : 03.01.09 - klo:15.52 »
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.

mgronber

  • Käyttäjä
  • Viestejä: 1458
    • Profiili
Vs: Ext4
« Vastaus #49 : 03.01.09 - klo:19.53 »
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.

Lainaus
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.

Koodia: [Valitse]
$ 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ä.

Lainaus
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?

Lainaus
Silti ext4: on implementoitu Online defragmentation ominaisuus.

Ei sitä vielä stablen julkaisun yhteydessä ollut valmiina ;)

Lainaus
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.

mgronber

  • Käyttäjä
  • Viestejä: 1458
    • Profiili
Vs: Ext4
« Vastaus #50 : 03.01.09 - klo:20.03 »
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?

Lainaus
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.

harrykaa

  • Vieras
Vs: Ext4
« Vastaus #51 : 03.01.09 - klo:21.24 »
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 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 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.

mgronber

  • Käyttäjä
  • Viestejä: 1458
    • Profiili
Vs: Ext4
« Vastaus #52 : 03.01.09 - klo:22.17 »
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?

Lainaus
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.

Lainaus
Minkälaisissa kokoonpanoissa katsot, mgronber, hyödyn ext4:stä olevan merkittävän?

Ainakin sellaisissa kokoonpanoissa joissa osiokoko ylittää 8 TiB.

Lainaus
"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.

Lainaus
One very important thing to keep in mind is that there is NOT Ext4 GRUB support.

Eli asia oli juuri niin miten epäilinkin.

Lainaus
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.

Lainaus
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.

Lainaus
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.

harrykaa

  • Vieras
Vs: Ext4
« Vastaus #53 : 03.01.09 - klo:22.41 »
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.

Ux64

  • Käyttäjä
  • Viestejä: 586
    • Profiili
Vs: Ext4
« Vastaus #54 : 05.01.09 - klo:08.27 »
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.

Fri13

  • Käyttäjä
  • Viestejä: 465
    • Profiili
Vs: Ext4
« Vastaus #55 : 05.01.09 - klo:14.26 »
Lainaus
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.

Lainaus
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.

Lainaus
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.

Lainaus
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 ;-)

Lainaus
Ihme kun ihmiset jänkkää vastaan eivätkä osaa lukea noita dokumentteja.
&
Lainaus
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ä.

Lainaus
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.

Lainaus
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ä.
« Viimeksi muokattu: 05.01.09 - klo:14.31 kirjoittanut Fri13 »

muep

  • Käyttäjä
  • Viestejä: 896
    • Profiili
Vs: Ext4
« Vastaus #56 : 05.01.09 - klo:23.36 »
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.  :)
[http://smolt.fedoraproject.org/show?uuid=pub_ac53b581-021a-4b76-bd14-e7d51f55462f]Pöytäkone[/url]
Läppäri

anttimr

  • Käyttäjä
  • Viestejä: 1625
    • Profiili
Vs: Ext4
« Vastaus #57 : 08.01.09 - klo:21.37 »
Lainaus
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.

Lainaus
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
Ubuntu 12.10 Quantal Quetzal

timbba

  • Käyttäjä
  • Viestejä: 1413
    • Profiili
Vs: Ext4
« Vastaus #58 : 09.01.09 - klo:07.21 »
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?
« Viimeksi muokattu: 09.01.09 - klo:07.24 kirjoittanut timbba »

Ux64

  • Käyttäjä
  • Viestejä: 586
    • Profiili
Vs: Ext4
« Vastaus #59 : 09.01.09 - klo:10.34 »
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.

Lainaus
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.

Lainaus
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ää.

« Viimeksi muokattu: 13.01.09 - klo:17.35 kirjoittanut Ux64 »