Kirjoittaja Aihe: 12.04 - Tuo vihdoin e4defrag:in  (Luettu 3050 kertaa)

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 752
  • Techie
    • Profiili
    • Sami Lehtinen
12.04 - Tuo vihdoin e4defrag:in
« : 09.02.12 - klo:20.58 »
Sitä on todellakin odoteltu, joskin tiedostojen kopiointi on toiminut ext4:n kanssa aikalailla hyvin jos joku tiedosto on pitänyt erikseen defragata.

BtrFS tuo sitten auto defragin mount optiona.

kw: defrag, defragment, ext4, levyn eheytys, eheyttää, Linux, levy, levyt, tiedosto, tiedostot, Ubuntu, eheyttäminen

_Pete_

  • Käyttäjä
  • Viestejä: 1799
  • Fufufuuffuuu
    • Profiili
Vs: 12.04 - Tuo vihdoin e4defrag:in
« Vastaus #1 : 10.02.12 - klo:11.06 »
Sitä on todellakin odoteltu, joskin tiedostojen kopiointi on toiminut ext4:n kanssa aikalailla hyvin jos joku tiedosto on pitänyt erikseen defragata.

Miksi tiedosto sitten pitäisi eriksee defragata?


Sami Lehtinen

  • Käyttäjä
  • Viestejä: 752
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: 12.04 - Tuo vihdoin e4defrag:in
« Vastaus #2 : 12.02.12 - klo:19.22 »
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ää.
« Viimeksi muokattu: 12.02.12 - klo:20.46 kirjoittanut Sami Lehtinen »

_Pete_

  • Käyttäjä
  • Viestejä: 1799
  • Fufufuuffuuu
    • Profiili
Vs: 12.04 - Tuo vihdoin e4defrag:in
« Vastaus #3 : 13.02.12 - klo:09.59 »

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.


http://dataexpedition.com/~sbnoble/Tips/filesystems.html

Erityisesti kohta: fragmentation and optimization


matsukan

  • Käyttäjä
  • Viestejä: 2144
    • Profiili
Vs: 12.04 - Tuo vihdoin e4defrag:in
« Vastaus #4 : 13.02.12 - klo:15.51 »
Nyt uskaltaa asentaa 12.04 koneeseeni.

http://www.webupd8.org/2012/02/more-classic-gnome-session-lands-in.html#disqus_thread

fallback saa koko ajan paremman tuen seuraavan lts julkaisua kohti mennessä.

-ps tais mennä väärään ketjuun,  ;D
« Viimeksi muokattu: 13.02.12 - klo:15.55 kirjoittanut syrtek66 »
Pohjois-pohjanmaa
-- motto:  backupin tarve huomataan aina liian myöhään

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 752
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: 12.04 - Tuo vihdoin e4defrag:in
« Vastaus #5 : 13.02.12 - klo:19.04 »
http://dataexpedition.com/~sbnoble/Tips/filesystems.html
Erityisesti kohta: fragmentation and optimization

Aika kevyttä, ei mitään uutta. Tuo mun esimerkki yllä oli worst case scenario. Mutta testasin normaalimpaa tilannetta, jossa levyillä on reilusti tilaa ja sinne tuupataan hitaasti tai vähän nopeammin kamaa.

Tulokset ovat melkoisen mielenkiintoisia, joskaan eivät mitenkään odottamattomia. Paitsi BtrFS:n surkea suoriutuminen ihmetyttää. Samalla voin todeta, että ext4 on todellakin loistava fragmentoitumisen torjunnassa niin kauan kun levyllä on edes kohtuullisesti tilaa.

Tulokset löytyy täältä: "Test: BtrFS, Ext4, Ntfs - Simple file allocation tests"

En pitäisi keskustelua aiheesta ollenkaan pahana. Olisi kiva kuulla näkemyksiä tästä asiasta.

Sen verran tuli muualla noottia tuohon mun kirjoitukseen, että jengi valitti Kernelin olevan kovin vanha. Raportoimani outoudet voivat olla korjattuna joissain viimeisimmissä testiversioissa.
« Viimeksi muokattu: 14.02.12 - klo:19.03 kirjoittanut Sami Lehtinen »