Miksi tiedosto sitten pitäisi eriksee defragata?
Se on kysymys johon esimerkiksi sysadmin osaa vastata parhaiten. Jokaisella on omat syynsä. Mutta jos otetaan tässä ihan konkreettinen esimerkki tuotantojärjestelmän puolelta.
1) Iso levy jolla satojatuhansia pieniä tiedostoa.
2) Kasvava SQL kanta samalla levyllä.
3) Disk full tilanne
4) Tuhotaan vaikka 150000 tiedostoa.
Tuon jälkeen olisi erittäin suotavaa defragata tuo SQL kanta, koska se on jo täysin räjähtänyt. Jos defragia ei tehdä ja kanta jatkaa kasvamistaan, se joutuu laajentumaan tuohon "tähtitaivaaseen" jonka tuo pienten tiedostojen poistaminen jätti jälkeensä. -> fragmentoituminen on suorastaan katastrofaalista.
Tuollaisten tiedoston linear read on kyllä hauskaa kuunneltavaa, koska tiedostossa ei ole käytännössä yhtenäisiä pätkiä muutamaa kymmentä kiloa pideminä sektioina. -> linear read muuttuu random seekiksi.
SSD:llä tuo ei ole niin iso ongelma, joskin noin paha fragmentaatio kuormittaa myös käyttöjärjestelmän puolta ja kirjanpitoa laskien tehokkuutta.
Näitä fragmentoitumis asioita olen tutkinut ja ext4 tuntuu olevan suorastaan loistava niin kauan kun levy ei tule täyteen. NTFS taas voi fragmentoida tiedostot todella pahasti ilman disk full tilannetta. Helpoin tapa saada täysin katastrofaalinen tilanne NTFS:llä on luoda valtava pakattu sparse file ja täyttää se random järjestyksessä. NTFS tosin kykenee fragmentoimaan myös kasvat tiedostot, ainoa tapa saada suhteelisen kokonaisia fileitä NTFS levyille on tehdä pre-allokointi ja sitten laittaa datat varattuun tilaan. Kaikkien ohjelmien pitäisi tietenkin tehdä näin, mutta eivät tee.
Ext4:lla on myös pre-allokointiin mahdollisuus, mutta monet sovellukset eivät tosin sitä (vielä) käytä. Sparse fileiden täyttöä olen testannut myös ext4:lla, ja tulos on yllättävän hyvä. Keskimäärin noin 2 megatavun ekstenttejä syntyy tiedostosta. Eli jos luodaan gigan tiedosto, fragmentoituu se ~500 palaan. Onhan sekin monta palaa, mutta paljon vähemmän kuin esimerkiksi kymmenet tuhannet palat joita syntyy helposti NTFS levyillä. Viimeksi kun ajoin tuollaisen testin sain muistaakseni noin 34800 palaa NTFS levyllä.
Edit: Tuli muuten tuosta esimerkistä mieleen, että osaakohan tuo e4defrag siirtää muita tiedostoja kohdetiedoston tieltä. Varmaan se osaa, kun ohjelmat ovat tämän homman osanneet jo 90 luvun alkupuolelta asti. Ilman tuota ominaisuutta tiedoston defragmentointi on todennäköisesti mahdotonta koska vapaa tila on niin pahasti fragmentoitunutta.
Edit2: Delayed allocation ja sen hyödyt näkyy hienosti kun käyttää filefrag softaa mm. btrfs tiedostojärjestelmän kanssa. Data kertyy ensin puskuriin ja sitten vasta niille valitaan levyltä paikka mihin ne tallennetaan.
Edit3: Hmm, joko hidas allokointi aiheuttaa ongelmia. Siis ei delayed allocation vaan allokointi joka tapahtuu liian hitaasti jotta delayed allocation voitaisiin täysin hyödyntää tms. Postaan kohta ihan oman jutun tästä ongelmasta. Mielenkiintoista. En vielä päättänyt postaanko ollenkaan suomeksi vai pistänkö suoraan G+:n. - Tai sitten sillä ei ole mitään tekemitä delayed allocationin kanssa. Pari testiä lisää ja tiedän enemmän mikä mättää ja miten, mutta se on aivan selvää että joku mättää.
Aihe: 12.04 - Tuo vihdoin e4defrag:in (Luettu 4256 kertaa)
