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