Osio, suuret tiedostot ja varausyksikön koko

[Jantunen]

Moi,

Pitäisi tiristää HTPC:n "media"-osiosta viimeisetkin tavut ja tehot irti kasvattamalla sen varausyksikön kokoa, mutta mistä tiedän mikä olisi optimaalinen koko varausyksikölle? Oletuksena ext4 käyttää 4KiB, mutta käsitykseni mukaan omassa tapauksessani tuo aiheuttaa paljon hukkatilaa, eli levy on 1TB levy, jossa siis n. 100G mp3-tiedostoja (olen yrittänyt rippailla kaikki 320kbps, joten ovat varmaan vähintään 7megaa per raita), loput menee leffoille ja TV-sarjoille (minimissään gigaisia tiedostoja kaikki).

Eli miten parhaiten tarkistan nykyisen "hukkatilan" ja miten pystyn vertaamaan sitä, jos kasvatan varausyksikön koon vaikka summamutikassa nelinkertaiseksi?

[jkw]

Moikka,

Eikös se ole ennemminkin toisinpäin, eli kun varausyksikön koko on pieni niin hukkatilaa ei kerry paljoakaan. Jos taas varausykikön koko olisi suurempi, ja levyllä olisi paljon tiedostoja jotka ovat kooltaan pienempiä kuin varausyksikkö, niin ne tiedostot veisivät kukin kuitenkin sen varausyksikön koon verran tilaa vaikka eivät tarvitsisi niin paljon? Ja joka tapauksessa kun tiedostot eivät ole kooltaan aina tuon varausyksikön kerrannaisia, niin osa viimeisestä tiedoston käyttämästä varausyksiköstä jää käyttämättä ja siitä aiheutuu hukkatilaa, mutta taaskin mitä isompi varausyksikkö sitä enemmän hukkatilaa.

Sinulla kun on pelkästään isompia tiedostoja levyllä, niin toki varausyksikköä voisi varmaan kasvattaakkin ja voihan näin mututuntumalta kai nopeuttaakin tiedostojen lukua kun ei tarvitse lukea niin monesta eri varausyksiköstä (jotka voivat olla levällään ympäri levyä), mutta hukkatilaa et sillä tavoin saa kyllä vähennettyä.

Jos sinulla on arviolta 15000 mp3 tiedostoa ja ne kaikki sattuisivat viemään keskimäärin puolet varausyksikön koosta hukkatilaa, olisi hukkatilan määrä noin 30mt (siis jos varausyksikkö on 4kt). Jos kasvatat varausyksikön koon nelinkertaiseksi kasvaa hukkatilakin nelinkertaiseksi eli 120mt, olettaen että jokainen tiedosto sattuu viemään hukkatilaa puolet varausyksikön koosta. Nappikauppaa sanon minä

[Jantunen]

Moikka,

Eikös se ole ennemminkin toisinpäin, eli kun varausyksikön koko on pieni niin hukkatilaa ei kerry paljoakaan. Jos taas varausykikön koko olisi suurempi, ja levyllä olisi paljon tiedostoja jotka ovat kooltaan pienempiä kuin varausyksikkö, niin ne tiedostot veisivät kukin kuitenkin sen varausyksikön koon verran tilaa vaikka eivät tarvitsisi niin paljon? Ja joka tapauksessa kun tiedostot eivät ole kooltaan aina tuon varausyksikön kerrannaisia, niin osa viimeisestä tiedoston käyttämästä varausyksiköstä jää käyttämättä ja siitä aiheutuu hukkatilaa, mutta taaskin mitä isompi varausyksikkö sitä enemmän hukkatilaa.

Sinulla kun on pelkästään isompia tiedostoja levyllä, niin toki varausyksikköä voisi varmaan kasvattaakkin ja voihan näin mututuntumalta kai nopeuttaakin tiedostojen lukua kun ei tarvitse lukea niin monesta eri varausyksiköstä (jotka voivat olla levällään ympäri levyä), mutta hukkatilaa et sillä tavoin saa kyllä vähennettyä.

Jos sinulla on arviolta 15000 mp3 tiedostoa ja ne kaikki sattuisivat viemään keskimäärin puolet varausyksikön koosta hukkatilaa, olisi hukkatilan määrä noin 30mt (siis jos varausyksikkö on 4kt). Jos kasvatat varausyksikön koon nelinkertaiseksi kasvaa hukkatilakin nelinkertaiseksi eli 120mt, olettaen että jokainen tiedosto sattuu viemään hukkatilaa puolet varausyksikön koosta. Nappikauppaa sanon minä

Tuokin on totta. Ajattelin sitä kautta, että jokainen varausyksikkö "syö" tilaa levyltä, eli varausyksikkö vaatii aina metatietoa, eli tietoa itse varausyksiköstä ja tämän overheadin haluaisin minimoida. Varausyksikön vaatima kirjanpitohan lienee sama oli yksikön koko kuinka suuri hyvänsä, mutta onko se riittävän suuri hyöty suhteessa mahdolliseen haittaan, jossa tiedostot jakautuvat huonosti viimeisten varausyksiköiden kanssa (tosin tässä tapauksessahan sitä tapahtuu melko vähän, kun tiedostot ovat kaikki suuria)

Tiedä nyt sitten mitä tehdä tämän kanssa

[_Pete_]

Täällä asiaan liittyen teknistä tarinointia:

http://lwn.net/Articles/469805/

[Jantunen]

Täällä asiaan liittyen teknistä tarinointia:

http://lwn.net/Articles/469805/

Hyvää tekstiä, muttei sekään tosiaan antanut suoraa vastausta. Taidan mennä EXT4:llä oletuksilla ja odotella, että BtrFS kypsyy...

[Sami Lehtinen]

Hyvää tekstiä, muttei sekään tosiaan antanut suoraa vastausta. Taidan mennä EXT4:llä oletuksilla ja odotella, että BtrFS kypsyy...

Eihän tuollaisiin kysymyksiin voi antaa suoria vastauksia, jotka riippuvat mm. käyttöpatterneista ja tietosisällöstä, järjestelmä arkkitehtuurista ja vaikka mistä.

Mutta joo, suorituskykyä voi paraa käyttämällä suurempia blokkeja, paljonko se käytännössä paranee ilmenee parhaiten mittaamalla. Olen kyllä antanut itseni ymmärtää että Ext4:n Extents käytäntö käytännössä merkitsisi sitä, että blokki koolla on paljon pienempi merkitys kuin mm. fat levyillä oli clustereilla.

http://computer-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents

Samaa asiaa kyselin myös täällä, mutta hieman eri asiayhteydessä:
http://forum.ubuntu-fi.org/index.php?topic=43119.0

[Postimies]

Kokeile XFS. Raivostuttavinta on isolla levyllä kun alkaa levyntarkistus ja se kestää ja kestää ja pitäs sitä leffaa päästä tallentamaan. Mutta jos on XFS ei huolta. Ja XFS on nopea isoilla tiedostoilla. Varsinkin katsotun leffan poistaa hetkessä. Ext taas raksuttaa aikansa..Kaikki media nyt XFS levyllä. Ei sen blokin koolla ole niin merkitystä. Mediatiedostot luetaan alusta loppuun ja kokonaan yleensä.