Sovelluskehitys ja ideologia / kehityssuunnat

[Ux64]

Koska tästä aiheesta riittää varmasti erilaisia näkemyksiä, ajattelin että on parempi pistää ihan oma ketjunsa.

Juttu lähti liikkeelle siitä että miksi Ubuntu ei tue NCQ:ta.

Oma näkemykseni asiaan:

Olen huomannut monessa yhteydessä että kun on selviä teknisiä parannuksia jotka pitäisi tehdä, niitä halutaan jostain syystä vastustaa viimeiseen asti. Tai niiden merkitystä vähätellään suuresti. - Tämä ei ole mitään uutta minulle, kun olen sovelluskehityksen parissa työskennellyt yli kymmenen vuotta. Omasta mielestäni erinäköiset optimoinnit pitäisi ottaa käyttöön kun se vain suinkin on mahdollista ja järkevää. Lisäksi jos joku asia on selvästi teorian tasolla osoitettu suorituskykyä parantavaksi, niin sen lyttääminen matonalle sillä perusteella että sitä ei tarvita on mielestäni väärin. Mutta ehkä tästä aiheesta voisi keskustella jossain ihan muussa ketjussa. Sanotaan vaan, että nyppii silloin kun asiasta on jäänyt jotain hampaankoloon. Olen kutenkin pohjimmiltani idealisti ja jos jotain voidaan parantaa, sitä pitäisi mielestäni parantaa. Eritoten kun kyseessä on käytettävyys tai optimointi. En kuitenkaan tue bloatwarea jossa varsinkin puutteellisisesti toimivia tai olennaisen kannalta tarpeettomia ominaisuuksia lisätään tolkuton määrä sovellukseen.

Yksi projekti jonka osalta olen monta kertaa sanonut tuhon olleen tulossa oli edonkey2000. eMuleen otettiin selvät loogiset parannukset käyttöön, mutta edonkey2000 ei niitä valitettavasti tukenut.

Tämä on varmasti koeteltu asia kyllä erilaisten distrojen tms asioiden puolesta ja yksi syy siihen miksi projekteja on niin monia. Demokratia kun ei välttämättä toimi aina yhtä tehokkaasti kuin diktatuuri.

Toinen referenssi on asiallisen ext3 defragin puute. Useimmat vastaajat eivät edes paneutuneet aiheeseen, vaan sanoivat että sitä ei tarvitse tehdä. Miksei? Missä selvät perustelut miksi ei? Niissäkin paikoissa joissa asiaa on perusteltu, sanotaan että fragmentoitumista imenee. Eikä sen jälkeen ole kerrottu mitään menetelmää joka eliminoisi sen. Näin ollen tilanne pahenee, vaikkakin hitaasti.

Tulen huomenna suorittamaan pari testiä NTFS:n pre-allokointiin liittyen, odotan innolla tuloksia. Tein sovelluksen joka allokoi levyltä 10% sen vapaasta tilasta. Toistan testit ennen ja jälkeen defragmentointia. Siten että toisella kerralla tila pre-allokoidaan ja toisella kerralla sitä ei varata. Otos on tietysti äärimmäisen pieni, mutta antaa edes jotain hajua asiaan josta on paljon spekulointia mutta ei mitään faktaa. Ainakin ideologisella tasolla pre-allokoinnin etu on selvä levyllä jossa on suhteellisen paljon tilaa.

Ihailen myös estotta projekteja joissa on oikeasti pyritty täydellisyyteen työmäärästä välittämättä. Töissä tulee jatkuvasti eteen resurssien riittämättömyys ja se, että joudutaan syöksymään pää kolmantena jalkana tuntemattomaan. Kun mielestäni erilaiset ratkaisut pitäisi arvioida jos on epäselvää, pitäisi simuloida ja testata tms. Voitaisiin siis tieteellisesti toistettavin tuloksin todeta, että tehdyt ratkaisut ovat oikeita.

[mgronber]

Aiheeseen liittyen: Why doesn't Linux need defragmenting?

Jos levy on niin täynnä että fragmentoitumisesta tulee ongelma niin silloin on aika ostaa uusi levy.

[Ux64]

Aiheeseen liittyen: Why doesn't Linux need defragmenting?

Jos levy on niin täynnä että fragmentoitumisesta tulee ongelma niin silloin on aika ostaa uusi levy.

Artikkelissa ei lainkaan mainittu sitä, miten pikkuhiljaa rakentuva fragmentoituminen poistuu. Vastaus on, se ei poistu. Missään ei mainita miten siitä vuosien mittaan kertyneestä fragmentoitumisesta pääsee eroon. Fragmentoitumisen parina NCQ olisi mainio lisä, mutta sekään ei toimi kun sitä ei kuulemma tarvita. Indeksitkin ovat mielestäni turhia tietokannoissa, koska järjestelmä _ei_ lakkaa toimimasta vaikka indeksejä ei käytettäisi ollenkaan. Suorituskyky voi tosin kärsiä, mutta se on toinen juttu. Lisäksi kannattaa pitää tietokannat riittävän pienenä, ettei suorituskykyongelma ilmene suhteessa järjestelmän tehoon.

Olen varsin hyvin tietoinen mainitsemastasi artikkelista ja olen myös siihen tutustunut ajatuksen kanssa.

Usein myös tilapäisesti levy voi olla hyvin täynnä. Tilanne on helppoa korjata, mutta tilanteessa syntynyt fragmentoituminen ei poistu mihinkään.

Erittäin mielenkiintoisia tuloksia, joskin NTFS:llä.

Testit:
 
w pre-allocation 8 fragmented files, 89 frags
 
w/o pre-allocation 200 fragmented files, 2152 frags

Total file count 1726, total size 800 MBytes.
 
Yep yep! Pre allokoinnilla olisi mahdollisuus merkittävästi vähentää fragmentoitumista, mutta kun sitäkään ei käytetä.

Toivoisin sinun esittävän näihin kahteen jo aikaisemminkin esittämääni ongelmaan ratkaisun. Eli miten syntynyt fragmentoituminen poistuu? Sekä miten fragmentoituminen estyy, vaikka levytilaa olisikin riittävästi? Entäs ne esimerkit joita oli mainittu ubuntuforumssissa? Esimerkiksi levyn tilasta 50% täytetään blockin kokoisilla tiedostoilla jonka jälkeen kirjoitetaan 20% levyn koosta täyttävä yksittäinen tiedosto levylle. Jos tuo ei aiheuttanut fragmentoitumista. Niin tehdäänpä niin päin että ei lisätä tuota 20% (levytilata) kokoista palikkaa vaan jatketaan noista jo kirjoitetuista tiedostoista 40% yhdellä blockilla? Miten nyt fragmentoituminen estyy?

Tietysti on määrittelykysymys, milloin esimerkiksi tietokannan indeksien puute (tai fragmentoituminen) lasketaan ongelmaksi. Olen monessa kirjoittamassani sovelluksessa käyttänyt helppouden vuoksi linked listejä objekteille joita käytetään usein. Suorituskyky kärsii, mutta ohjelma toimii. Muina kätevinä ratkaisuina fragmentoitumisen ongelman poistamiseen näkisin esimerkiksi sen, että järjestelmän musiti vastaa levytilaa ja järjestelmää ei käynnistetä turhan usein uudelleen. Silloin olen sitä mieltä, että fragmentoituminen ei ole ongelma, kun koko levyn sisältö mahtuu välimuistiin. Tietysti cache flushit edelleen hidastuvat fragmentoitumsen myötä, mutta nekin voitaisiin suorittaa tarpeeksi harvoin.

Tänään asentaessani Mokkulaa huomasin ohjekirjassa maininnan. Mikäli kone on hitaampi kuin suositeltu, voi mokkulan käyttäminen aiheuttaa järjestelmän hidastumista. Hetkonen? Eikö nopeampi järjestelmä sitten hidastu? Otetaan esimerkki. Tuote maksaa 1000 euroa. Jos sen ostaa ihminen jolla on vain 3000 euroa, hän köyhtyy 1000 euroa. Jos sen ostaa ihminen joka on miljardööri, hän köyhtyy 1000 euroa? Miten Mokkula siis hidastaa vain hidasta konetta? Mielenkiintoisia insinöörejä tuolla Mokkula tiimissä. Tai sitten he ovat saavuttaneet jonkinlaisen suprajohtavuden tai kuormittamattomuuden tilan kun koneen kuormitus on suhteellisesti riittävän pieni sen resursseihin? Auttaisiko jos ajaisin miljoonana threadina jotain tehtävää yhden threadin sijasta? Kutistuisiko suoritusaika sellaiseksi että sitä ei pystytä mittaamaan? Auttaisiko jos rekursiivisesti vielä pilkkoisi tehtävän uudestaan miljoonaan threadiin?

Sinänsä on ihailtaavaa että ihmiset uskovat väitteitä joille ei ole loogista ja johdonmukaista selitystä. Täyttämällä kirjekuoria kotonasi tulet miljonääriksi ensivuonna. Toisaalta, olen myös havainnut että loogiset operaatiot eivät ole noin 90% ihmisistä lainkaan loogisia.

[moonstone]

Käsittääkseni linux kernel tukee NCQ:ta (ainakin intelin emoilla, jos se nyt siitä riippuu)
http://linux-ata.org/driver-status.html#ahci

Tiedostojärjestelmän fragmentoitumisesta en tiedä, mutta tldp sanoo seuraavaa
Modern Linux filesystem keep fragmentation at a minimum by keeping all blocks in a file close together, even if they can't be stored in consecutive sectors. Some filesystems, like ext3, effectively allocate the free block that is nearest to other blocks in a file. Therefore it is not necessary to worry about fragmentation in a Linux system.

En tarkempaa syytä tiedä miksei ole olemassa ext3 defragment työkalua, jos sellaista tarvitsee joutuu varmaan tekemään sen itse, tai maksaa jollekin sen tekemisestä

[Ux64]

Käsittääkseni linux kernel tukee NCQ:ta (ainakin intelin emoilla, jos se nyt siitä riippuu)
http://linux-ata.org/driver-status.html#ahci

Jonkinlaisilla experimental virityksillä, joo. Käytössä on Intelin IP35 chipsetillä oleva lankku. Sanoivat kuitenkin että sen käyttöönotto on niin vaikeaa ja työlästä, että parempi olla ilman. Eli tuotekehitys ei ole siinä mielessä vielä valmista. Asiaa tutkiessani huomasin myös, että vanhempi noin 3 vuotta vanha kiintolevyni tukee myös NCQta. Se oli minulle yllätys. Kyseessä ei ole siis selvästi myöskään mikään uusi asia. Näköjään 2004 tuli nuo NCQta tukevat SATA asemat myyntiin.

Tiedostojärjestelmän fragmentoitumisesta en tiedä, mutta tldp sanoo seuraavaa
Modern Linux filesystem keep fragmentation at a minimum by keeping all blocks in a file close together, even if they can't be stored in consecutive sectors. Some filesystems, like ext3, effectively allocate the free block that is nearest to other blocks in a file. Therefore it is not necessary to worry about fragmentation in a Linux system.

Kyllä. Tuo auttaa varmasti pitämällä fragmentoituneet palat kasassa, eli lähellä toisiaan. Myös extents tuki auttaisi varmasti, jossa blokkeja niputetaan kasoihin. Ja välejä aletaan syömään vasta kun tila on vähissä.  Mutta tuokaan ei eliminoi fragmentoitumista. Mielestäni suurin ongelma onkin juuri fragmentoituminen joka rakentuu ajan myötä usein käytettyihin tiedostoihin. Sekä siitä seuraava vapaan tilan fragmentoituminen. Riippuen käytettävistä puskuroinneista myös yhdessä pitämisestä voi olla haittaa. Ainakin FAT aikoina pystyi luomaan tiedoston jonka kaikki clusterit olivat käänteisessä järjestykessä levyllä. Eli loogisesti seuraava klusteri tiedostossa oli levyllä aina loogisesti edelinen klusteri. Arvaa kuinka hidasta tuollaisen levykkeen lukeminen oli? Sen sijaan että levyn yksi kierros olisi lukenut kaikki levyn yhden puolen trackin clusterit. Oli lopputulos se että vain yksi klusteri tuli luetuksi. Myös väärin säädetyllä interleavella saattoi romahduttaa levyn suorituskyvyn. Kun interleave on oikea, kerkiää headit siirtymään juuri seuraavan trackin alkuun samaan tahtiin kuin levy pyörii. Kun interleave on väärin, joudutaan jokaisen siirtymän välissä odottamaan täysin levyn kierros.

NCQ:n tarkoituksena on juuri optimoida tällaisia tilanteita. Käsittääkseni tahalleen tehty takaperoinen kirjoitus levylle nopeutusi NCQ:lla 32 kertaisesti. Vielä suurempi erotus saataisiin mikäli klusterit sijoitettaisiin tahallisesti levygeometrian molempiin ääripäihin joka toinen järjestyksessä.

ext3:n tapauksessa juuri se että fragmentoituituneen tiedoston sisätö ja sen mudostavat blockit ovat lähellä toisiaan antaisi NCQ:n kanssa kohtuullisen hyödyn, kun tiedot voidaan lukea parhaassa järjestyksessä, eikä blokkien loogisessa järjestyksessä.

Haarukoinnissa on mielestäni hyvä lähteä molemmistaa ääripäistä. Jos toinen ääripää on sama kuin toinen, voidaan olettaa ettei em. menetelmistä ole mitään hyötyä.

Luuletteko että NCQ on tehty sen takia ettei siitä ole mitään hyötyä? Niin paljon kun rakastakin markkinointimiehiä, kuulostaisi slougani mielestäni oudolta: "Olemme jälleen käyttäneet useita  miljoonia kehittääksemme ominaisuuden josta ei ole sinulle mitään hyötyä?". Hmm, ei kuulosta hyvältä businekselta. Ehkä siis NCQ:ssa pitäisi olla joku juju, vaikka Linux käyttäjät kovasti sanovatkin foorumeissa ettei siitä ole mitään hyötyä.

[mgronber]

En tarkempaa syytä tiedä miksei ole olemassa ext3 defragment työkalua, jos sellaista tarvitsee joutuu varmaan tekemään sen itse, tai maksaa jollekin sen tekemisestä

Wikipedian mukaan ext4 tukee online defragmentointia. Sen vuoksi ei mielestäni ole enää järkevää tehdä ext3:lle minkäänlaista defragmentointityökalua.

[Ux64]

Wikipedian mukaan ext4 tukee online defragmentointia. Sen vuoksi ei mielestäni ole enää järkevää tehdä ext3:lle minkäänlaista defragmentointityökalua.

Kyllä. Ext4:ssa on monia olennaisia parannuksia, nimenomaan fragmentoitumiseen liittyen. Pre-allcation, delayed allocation, extents ja tuo mainitsemasi online defragmentation.

Ihmettelenkin kovasti miksi ne on tehty, kun vakaasti on väitetty ettei em. toimenpiteistä ole mitään hyötyä?

Omituista, sano...

[mgronber]

Wikipedian mukaan NCQ jopa hidastaisi toimintaa tietyissä tapauksissa: "However, the current (as of 2004) technology actually slows down HD access in certain applications, like games and sequential reads & writes, because of the added latency induced by NCQ logic."

NCQ:n tarkoituksena on juuri optimoida tällaisia tilanteita. Käsittääkseni tahalleen tehty takaperoinen kirjoitus levylle nopeutusi NCQ:lla 32 kertaisesti.

Voisin kuvitella että tahallisesti takaperoisesti tehty kirjoitus käännetään oikein päin levypuskureissa.

Vielä suurempi erotus saataisiin mikäli klusterit sijoitettaisiin tahallisesti levygeometrian molempiin ääripäihin joka toinen järjestyksessä.

Et sitten mitään epärealistisempaa esimerkkiä viitsinyt mainita? On turhaa spekuloida ongelmilla joita tulisi siinä tilanteessa että noin matalalla tasolla tehtäisiin jotakin tahallisesti väärin. Tuollaiset ongelmat eivät ole realistisia.

ext3:n tapauksessa juuri se että fragmentoituituneen tiedoston sisätö ja sen mudostavat blockit ovat lähellä toisiaan antaisi NCQ:n kanssa kohtuullisen hyödyn, kun tiedot voidaan lukea parhaassa järjestyksessä, eikä blokkien loogisessa järjestyksessä.

Jälleen tiedostojärjestelmä ja levypuskurit saattavat korjata tämän ilman mitään tarvetta NCQ:lle.

Luuletteko että NCQ on tehty sen takia ettei siitä ole mitään hyötyä?

Onhan eräässäkin tiedostojärjestelmässä tehty keinotekoinen laajennus jotta siellä pystytään esittämään yli 8+3 merkin mittaisia tiedostonimiä. Se ei kuitenkaan tarkoita että sama ongelma olisi muissakin tiedostojärjestelmissä ja että niissä tarvittaisiin samaan ongelmaan ratkaisua.

NCQ voisi aivan hyvin olla luotu pelkästään FAT:n tai NTFS:n puutteiden kompensoimiseksi. En väitä että näin olisi mutta se olisi täysin mahdollista.

[Vapaan koodin kananmuna]

Luuletteko että NCQ on tehty sen takia ettei siitä ole mitään hyötyä? Niin paljon kun rakastakin markkinointimiehiä, kuulostaisi slougani mielestäni oudolta: "Olemme jälleen käyttäneet useita  miljoonia kehittääksemme ominaisuuden josta ei ole sinulle mitään hyötyä?". Hmm, ei kuulosta hyvältä businekselta. Ehkä siis NCQ:ssa pitäisi olla joku juju, vaikka Linux käyttäjät kovasti sanovatkin foorumeissa ettei siitä ole mitään hyötyä.

Käsittääkseni ncq on joiltain asemilta (ainakin hitachia löytyi launchpadista) poistettu käytöstä sen aiheuttamien ongelmien takia.
Ncq:n vaikutukset suorituskykyyn on ainakin niiden testien mukaan joita olen lukenut melko pieni ja joissain operaatioissa jopa haitallinen. Palvelinkäytössä ilmeisesti yleensä parantaa suorituskykyä.
Edit: mgronber kerkesi ensin.

[Ux64]

Voisin kuvitella että tahallisesti takaperoisesti tehty kirjoitus käännetään oikein päin levypuskureissa.

Kyllä mahdollisesti, koska se olisi kieltämättä järkevää. Ehkä siinä mielessä huono esimerkki. NCQ:n dokumentoinnissa mainitaankin ensisijaisena tavoitteen saada luvut optimoitua levygeometrian mukaisesti. Tästä asiasta minulla ei valitettavasti ole vahvaa mielipidettä tiedonpuutteen vuoksi. Mutta olen antanut itseni ymmärtää että nykyiset SATA levyt aika hyvin piilottavat levyn todellisen geometrian. Jolloinka käyttöjärjestelmä ei välttämättä pysty optimoimaan lukuja tehokkaimmalla mahdollisella tavalla. Täytyy jatkaa aiheesta lukemista. SCSI puolella TCQ on vanha juttu. Sinnekkin se on ilmeisesti syystä tehty.

Et sitten mitään epärealistisempaa esimerkkiä viitsinyt mainita? On turhaa spekuloida ongelmilla joita tulisi siinä tilanteessa että noin matalalla tasolla tehtäisiin jotakin tahallisesti väärin. Tuollaiset ongelmat eivät ole realistisia.

Täysin totta. Mainitsemasi levypuskurit voisivat poistaa tämän ongelman, kuten mainitsit. Tämä olikin lähinnä worst case scenario. Onko kenelläkään tietoa siitä tallentavatko levyt välimuistiin myös sen datan joka on luettu vaikka sitä ei ole pyydetty luettavaksi? Sillä olisi luonnollisesti äärimmäisen suuri vaikutus tuohon takaperoiseen kirjoitustilanteeseen. Monissa levyissä kun on nykyjään aika mittavia välimuisteja. Käyttöjärjestelmä levylläni on 32 megatavun välimuisti ja kakkoslevylläkin 16 megatavun.

NCQ voisi aivan hyvin olla luotu pelkästään FAT:n tai NTFS:n puutteiden kompensoimiseksi. En väitä että näin olisi mutta se olisi täysin mahdollista.

Hyvä esitys.

- Kiitos, sain vihdoinkin erinomaisia vastaesityksiä yleisen höpinän ja linkkien (jotka eivät sisällä mitään olennaista) sijasta.

Käsittääkseni ncq on joiltain asemilta (ainakin hitachia löytyi launchpadista) poistettu käytöstä sen aiheuttamien ongelmien takia.

Tuo asia valitettavasti koskee useita uusia teknologioita. Kunhan koko ketju on saatu kuntoon rauta, firmikset, ajurit tms. Niin sitten homma alkaa toimimaan. Kehitys on jo niin pitkällä että monet suorituskykyä parantavat tekniikat ovat monimutkaisia eivätkä silti tuo suuren suuria parannuksia. Kuitenkin kun ne pienetkin parannukset lasketaan yhteen saadaan siitä toivottavasti merkittävää hyötyä.

Samoin kaikki levyjensuorituskykyä parantavat tekniikat ovat mielestäni todella tervetulleita. Levyt ovat selvästi järjestelmän hitain komponentti useimmissa nykyisissä koneissa ja tehtävissä. Silloinkin kun käyttäjä odottaa koneelta vastausta suurin osa odottelusta on joko verkosta tai levystä kiinni riippuen tehtävän luonteesta.

[mgronber]

Olen varsin hyvin tietoinen mainitsemastasi artikkelista ja olen myös siihen tutustunut ajatuksen kanssa.

Hieman sitä epäilinkin mutta laitoin sen kuitenkin koska täällä on varmasti paljon muita joille siitä on hyötyä.

 

Erittäin mielenkiintoisia tuloksia, joskin NTFS:llä.

Testit:
 
w pre-allocation 8 fragmented files, 89 frags
 
w/o pre-allocation 200 fragmented files, 2152 frags

Total file count 1726, total size 800 MBytes.

Sitten kun saisi hieman vastaavia lukuja esimerkiksi ext3:lla niin noillakin luvuilla olisi jotakin merkitystä.

Yep yep! Pre allokoinnilla olisi mahdollisuus merkittävästi vähentää fragmentoitumista, mutta kun sitäkään ei käytetä.

Tuon testin perusteella sillä on mahdollista vähentää fragmentoitumista NTFS:llä. Tuo testi ei kerro mitään muuta.

Toivoisin sinun esittävän näihin kahteen jo aikaisemminkin esittämääni ongelmaan ratkaisun. Eli miten syntynyt fragmentoituminen poistuu?

Kopioidaan datat sille juuri ostetulle uudelle kiintolevylle

Sekä miten fragmentoituminen estyy, vaikka levytilaa olisikin riittävästi?

Ensiksi pitäisi osoittaa että aiheutuu merkittävästi nopeuteen vaikuttavaa fragmentoitumista.

Entäs ne esimerkit joita oli mainittu ubuntuforumssissa?

En ole vielä ehtinyt lukemaan...

Esimerkiksi levyn tilasta 50% täytetään blockin kokoisilla tiedostoilla jonka jälkeen kirjoitetaan 20% levyn koosta täyttävä yksittäinen tiedosto levylle. Jos tuo ei aiheuttanut fragmentoitumista. Niin tehdäänpä niin päin että ei lisätä tuota 20% (levytilata) kokoista palikkaa vaan jatketaan noista jo kirjoitetuista tiedostoista 40% yhdellä blockilla? Miten nyt fragmentoituminen estyy?

Oliko tavoitteena estää fragmentoituminen silloin kun yritetään fragmentoida vai estää se normaalissa käytössä?

Jos levyllä on noinkin paljon yhden blokin kokoisia tiedostoja niin silloin käytössä on väärä tiedostojärjestelmä sillä reiserfs, killer filesystem, pärjää niiden kanssa huomattavasti paremmin.

Edit: Tuo esimerkki ei muuten ole mahdollinen jos ext3-osio on luotu vakioparametreilla: inodet loppuvat kesken.

[Ux64]

Tuon testin perusteella sillä on mahdollista vähentää fragmentoitumista NTFS:llä. Tuo testi ei kerro mitään muuta.

Jos pre-allokointia ei tehdä, fragmentoitumista tulee aina enemmän. Koska silloin tiedosta ei voida sijoittaa "oikein".

Kopioidaan datat sille juuri ostetulle uudelle kiintolevylle

inode järjestelmään en ole tutustunut kunnolla. Jos ymmärsin oikein tuon artikkelin jossa selitettiin miksi defragmentointia ei tarvita. Niin sen perusteella uskoisin että edes datan kopiointi lähteestä A kohteesen B ei johda tilanteeseen jossa fragmentoitumista ei olisi. FAT:illa sen saisi johtamaan siihen tilanteeseen. Mutta käsittääkseni ext3:lla ei. Johtujen juuri siitä että tiedostoja _ei_ sijoiteta tiiviiksi pötköksi. Eli tässä tapauksessa "parempi tiedostojärjestelmä" tai tietojen sijoittamismenetelmä on huonompi. Kaikissa ratkaisuissa kun tuntuu olevan kaksi puolta.

Oliko tavoitteena estää fragmentoituminen silloin kun yritetään fragmentoida vai estää se normaalissa käytössä?

Esimerkkini vastaa normaalikäyttöä. Eli levylle lisätään ja sieltä poistetaan hyvin suuria määriä pieniä tiedostoja ja siellä on muutamia jatkuvasti kasvavia suuria tiedostoja. Tämä on suora esimerkki esim. meidän data exchange serveriltä. Muutama kymmenien gigojen jatkuvasti kasvava tiedosto ja kymmeniätuhansia pieniä. Kun levy on suhteellisen täynnä pieniä tiedostoja siivotaan pois. -> Johtaa vapaantilan fragmentoitumiseen ja myös sitä myöten noiden isojen tiedostojen fragmentoitumiseen.

Mun mielestä insinöörit ja asiantuntijat ovat nyt kyllä puhuneet itsensä aika pahasti pussiin. Koska tekevät sellaista asiaa (ext4:ssa) jolla ei todistettavasti ollut mitään merkitystä(?). Musta niiden toimita on siis vähintäänkin epäloogista. Ehkä IT hommiin ja sovelluskehitykseen pitäisi kuitenkin hankkia loogisia järki ihmisiä ailahtelevien tunne ihmisten sijaan?

[Tommi S.]

Tänään asentaessani Mokkulaa huomasin ohjekirjassa maininnan. Mikäli kone on hitaampi kuin suositeltu, voi mokkulan käyttäminen aiheuttaa järjestelmän hidastumista. Hetkonen? Eikö nopeampi järjestelmä sitten hidastu? Otetaan esimerkki. Tuote maksaa 1000 euroa. Jos sen ostaa ihminen jolla on vain 3000 euroa, hän köyhtyy 1000 euroa. Jos sen ostaa ihminen joka on miljardööri, hän köyhtyy 1000 euroa? Miten Mokkula siis hidastaa vain hidasta konetta? Mielenkiintoisia insinöörejä tuolla Mokkula tiimissä. Tai sitten he ovat saavuttaneet jonkinlaisen suprajohtavuden tai kuormittamattomuuden tilan kun koneen kuormitus on suhteellisesti riittävän pieni sen resursseihin? Auttaisiko jos ajaisin miljoonana threadina jotain tehtävää yhden threadin sijasta? Kutistuisiko suoritusaika sellaiseksi että sitä ei pystytä mittaamaan? Auttaisiko jos rekursiivisesti vielä pilkkoisi tehtävän uudestaan miljoonaan threadiin?

Sinänsä on ihailtaavaa että ihmiset uskovat väitteitä joille ei ole loogista ja johdonmukaista selitystä. Täyttämällä kirjekuoria kotonasi tulet miljonääriksi ensivuonna. Toisaalta, olen myös havainnut että loogiset operaatiot eivät ole noin 90% ihmisistä lainkaan loogisia.

Auttaisiko tähän mokkulaesimerkkiin vertaus "mokkula toimii 12 voltin jännitteellä. Jos jännitelähteen virransyöttökyky ei ole riittävä saattaa jännite laskea alle 12 volttiin"? Vertaukset voivat olla täysin loogisia, mutta ne voivat myös olla tilanteeseen nähden vääriä.

Neurologi Antonio Damasio kertoi jossain kirjassaan miehestä joka sai onnettomuuden seurauksena aivovaurion. Mies pystyi toivuttuaan palaamaan töihin, ja hän osasi kaikki loogiset vaiheet työstään aivan kuten ennenkin, mutta hän ei saanut mitään tehtyä sillä hän ei enää kyennyt käsittämään mitkä asiat kannatti tehdä ja mitkä kannatti jättää tekemättä. Hän saattoi esimerkiksi huomata että kirjahyllyn kirjat ovat väärässä järjestyksessä, ja hän osasi kyllä täysin loogisesti järjestellä kirjat oikeaan järjestykseen, mutta koko työpäivänä hän ei sitten saanutkaan mitään muuta aikaiseksi.

Sellainen idealismi että asiat kannattaa tehdä jos vain pystyy, koska se on hyvää tai kaunista tai oikein, ei välttämättä ole mitenkään loogista, vaan sen voidaan nähdä myös olevan tunteellisuutta.

Se pointti siinä Damasion kirjassa oli että tunteet ovat välttämätön osa järkevää toimintaa, sillä tunteet määräävät mitkä asiat ovat tärkeitä ja mitkä vähemmän tärkeitä. Millaisessa käytössä ja missä ajassa ext3 alkaa fragmentoitumaan huomattavasti? Jos ext3 otettiin käyttöön joskus vuonna 2000, niin ehkä onkin niin että ne ensimmäiset vuodesta 2000 lähtien pyörineet järjestelmät alkavat vasta nyt osoittamaan sirpaloitumista, tai ehkä vasta nykyisillä kovalevytilavuuksilla sirpaloituminen alkaa olla ongelma, ja siksi juuri nyt on aika kehittää ext3:lle seuraaja joka osaa eheyttää itsensä, mutta tuo aika ei välttämättä ollut aikaisemmin. Idealistisesti suhtautuvan mielestä eheytys olisi pitänyt ottaa mukaan jo aikoja sitten, muttä tämä on idealistien tunteeseen perustuva arvovalinta, eikä sellaisenaan mitenkään loogisempi tai epäloogisempi kuin pragmatistien arvovalinta.

GNU-projektin kerneli lähti idealistisesta lähtökohdasta, ja paperilla se on loogisesti parempi kuin monet muut. Torvaldsin kerneli taas lähti käytännönläheisestä lähtökohdasta, eli tehdään semmoinen mikä osataan ja koitetaan saada se toimimaan. Vaikka Linux olisikin teoreettisesti huonompi kuin Hurd, niin darwinistinen luonnonvalinta aiheutti sen että toimiva ratkaisu lisääntyi ja täytti maan. Hurd voi vielä vallata markkinaosuudet kaikilta muilta, mutta minkälainen maailma olisi jos kaikki olisivat 80-luvulta lähtien vain keskittyneet Hurdin kehittämiseen ja unohtaneet Linuxin, sillä vaikka Linux toimi ja Hurd ei, niin Hurd oli idealistiselta kannalta parempi.

[mgronber]

Tuon testin perusteella sillä on mahdollista vähentää fragmentoitumista NTFS:llä. Tuo testi ei kerro mitään muuta.

Jos pre-allokointia ei tehdä, fragmentoitumista tulee aina enemmän. Koska silloin tiedosta ei voida sijoittaa "oikein".

Mutta oleellista on kuinka paljon sitä tulee ja missä määrin se vaikuttaa nopeuteen. Jos toteat että NTFS:llä tuo pienentää merkittävästi fragmentoitumista niin se ei kerro vielä mitään tilanteesta muilla tiedostojärjestelmillä. Sittenkin kun saat testattua syntyvän fragmentoitumisen määrän niin sekään ei vielä kerro järjestelmän nopeudesta mitään. Jos tiedosto on fragmentoitunut niin on tärkeää tietää kuinka moneen palaan se on fragmentoitunut ja miten palat sijaitsevat toisiinsa nähden.

Kopioidaan datat sille juuri ostetulle uudelle kiintolevylle

inode järjestelmään en ole tutustunut kunnolla. Jos ymmärsin oikein tuon artikkelin jossa selitettiin miksi defragmentointia ei tarvita. Niin sen perusteella uskoisin että edes datan kopiointi lähteestä A kohteesen B ei johda tilanteeseen jossa fragmentoitumista ei olisi. FAT:illa sen saisi johtamaan siihen tilanteeseen. Mutta käsittääkseni ext3:lla ei. Johtujen juuri siitä että tiedostoja _ei_ sijoiteta tiiviiksi pötköksi.

Ei se sitä välttämättä kokonaan poista mutta väitän että isompaan levyyn vaihdettaessa ja datat kopioitaessa mahdollisella fragmentoitumisella ei ole käytännön vaikutusta nopeuteen. Jos fragmentoitumisen haluaa tuossa minimoida niin se onnistunee kopioimalla tiedostot suuruusjärjestyksessä suurimmasta pienimpään.

Eli tässä tapauksessa "parempi tiedostojärjestelmä" tai tietojen sijoittamismenetelmä on huonompi. Kaikissa ratkaisuissa kun tuntuu olevan kaksi puolta.

Niin, jos haluat tehdä read-only-järjestelmän niin FAT on parempi. Ext3 on tehty read-write-käyttöä varten jolloin hajasijoitus on järkevää. Jos gigan tiedosto fragmentoituu muutamaksi satojen megojen palaseksi niin se ei hirveästi vaikuta toimintaan.

Oliko tavoitteena estää fragmentoituminen silloin kun yritetään fragmentoida vai estää se normaalissa käytössä?

Esimerkkini vastaa normaalikäyttöä.

Jos sinusta normaalikäyttöä on sellainen tilanne joka ei Ext3:n oletusasetuksilla ole edes mahdollinen niin sitten meillä on kovasti erilainen käsitys normaalikäytöstä. Esimerkissäsi tiedostoja luotiin liikaa.

Eli levylle lisätään ja sieltä poistetaan hyvin suuria määriä pieniä tiedostoja ja siellä on muutamia jatkuvasti kasvavia suuria tiedostoja.

Tuossa tulee heti mieleen että olisiko isot ja pienet tiedostot mahdollista sijoittaa eri levyille? Se tuntuisi hyvin loogiselta ja yksinkertaiselta ratkaisulta.

Mun mielestä insinöörit ja asiantuntijat ovat nyt kyllä puhuneet itsensä aika pahasti pussiin. Koska tekevät sellaista asiaa (ext4:ssa) jolla ei todistettavasti ollut mitään merkitystä(?).

Niiden merkitystä ovat saattaneet lisätä esimerkiksi suuremmat tiedostojen ja levyjen koot. Jos pienet tiedostot ovat kovasti pirstaloineet levyä niin tämä tietysti lisää suurten tiedostojen fragmentoitumistodennäköisyyttä ja -määrää. Nykyiset suuret tiedostot ovat muutaman vuoden takaisiin tiedostoihin nähden valtavia. Ei tarvitse mennä ajassa hirveän paljon taaksepäin niin nykyiset suuret tiedostot eivät välttämättä olisi edes mahtuneet yhdelle levylle.

Kehitys jatkuu edelleen samaan suuntaan joten tähän liittyvät ongelmat todennäköisesti kasvavat. Uutta järjestelmää suunniteltaessa nämä asiat on syytä ottaa huomioon.

[Risto H. Kurppa]

Siirsin keskustelun yleistä keskustelua -alueelta tänne, on sen verran perusteellista juttua

r

[lompolo]

Esimerkkini vastaa normaalikäyttöä. Eli levylle lisätään ja sieltä poistetaan hyvin suuria määriä pieniä tiedostoja ja siellä on muutamia jatkuvasti kasvavia suuria tiedostoja. Tämä on suora esimerkki esim. meidän data exchange serveriltä. Muutama kymmenien gigojen jatkuvasti kasvava tiedosto ja kymmeniätuhansia pieniä. Kun levy on suhteellisen täynnä pieniä tiedostoja siivotaan pois. -> Johtaa vapaantilan fragmentoitumiseen ja myös sitä myöten noiden isojen tiedostojen fragmentoitumiseen.

Tottakai fragmentoitumista tapahtuu kun levylle kirjoitetaan ja ei etukäteen tiedetä kaikkea, mitä kirjoitetetaan. Eri asia on vaikuttaako se merkittävästi.

Voisit kokeilla laittaa nuo pienet tiedostot yhdelle omalle osiolle ja isot tiedostot toiselle omalle osiolle. Osiot voit halutessasi säätää käyttötarkoitukseesi sopivaksi. man mksf.ext3 auttaa. Voit sitten kertoa voititko jotain. Näin voit osoittaa levysi fragmentoitumisesta johtuvan haitan. Jos optimoit tiedostojärjestelmäsi, saatat saada muutakin pientä etua nykytilanteeseen verrattuna.

Oma käyttöni on niin tavallista, etten jaksa noin pieniä optimointeja tehdä.

[Timo Jyrinki]

Luuletteko että NCQ on tehty sen takia ettei siitä ole mitään hyötyä? Niin paljon kun rakastakin markkinointimiehiä, kuulostaisi slougani mielestäni oudolta: "Olemme jälleen käyttäneet useita  miljoonia kehittääksemme ominaisuuden josta ei ole sinulle mitään hyötyä?". Hmm, ei kuulosta hyvältä businekselta. Ehkä siis NCQ:ssa pitäisi olla joku juju, vaikka Linux käyttäjät kovasti sanovatkin foorumeissa ettei siitä ole mitään hyötyä.

http://www.storagereview.com/ on aika paljon testaillut kovalevyjä ja lienee luotettavimpia kovalevyjä testaavista sivustoista. Aika monesti NCQ hidastaa työpöytäkäytössä käyttöä hieman tai sillä ei ole vaikutusta. Uusimmilla kovalevyillä valmistajat ovat saaneet muutaman prosentin eron yleensä NCQ:n hyväksi. Eroja löytyy palvelinkäytössä kyllä enemmänkin, tosin silloin varmaan usein 10-15krpm SCSI-levyt voivat olla enemmän tarpeen.

Ja siis tämän pätkän tekstistäsi lainasin siksi että kyllä, niitä hyödyttömiäkin tekniikoita kehitetään miljoonilla. Silloin kun miljoonia on jo pistetty johonkin kehitykseen, usein halutaan että "kyllä se nyt on pakko pistää ulos kun siihen on niin paljon satsattu". Ja toisekseen usein kehitetään tekniikoita jotka ovat puhtaasti markkinointia minkään hyödyn sijaan, kuten lähes kaikki äänen"parannus"teknologiat kuten Creativen X-Fi-äänikorttien superominaisuudet - "tee MP3:stasi tämän käyrän osoittaman verran paremman kuuloista kuin CD:n ääni" - jjep.

No NCQ ei toki ole vaporwarea, ja tukeakin sille kernelissä on. Kuten kaikissa avoimen lähdekoodin projekteissa, tuki kytketään päälle kun sillä on riittävästi merkitystä jollekin niin että koodi saadaan kunnolla valmiiksi. Voi olla että kaikista näistä NCQ:n ongelmista ja lähes häviävän pienistä hyödyistä (poislukien SATA-levyjen palvelinkäyttö) johtuen yhtäkään aihetta tuntevaa kehittäjää ei asia vain ole kiinnostanut riittävästi. SATA-levyjen palvelinkäytön hyötyjen takia luulisi tosin aiheuttavan riittävää kiinnostusta.

Itse olin kyllä tosiaan siinä käsityksessä että NCQ:ta tuetaan jo useimmilla SATA-ohjaimilla, kuten kaikilla AHCI-standardia noudattavilla. Esim. http://linux-ata.org/software-status.html#tcq sanoo NCQ:sta "#3 is supported by libata, for most hardware and devices that support NCQ. "

[Ux64]

Quotet vähän sekavasti, mutta siis lompolon quotet alkuosassa ja puolen välin alapuolella Timon.

Tottakai fragmentoitumista tapahtuu kun levylle kirjoitetaan ja ei etukäteen tiedetä kaikkea, mitä kirjoitetetaan. Eri asia on vaikuttaako se merkittävästi.

Tuo on mielestäni hyvä kysymys jälleen. Mikä on merkittävää? Riippuu varmasti käytöstä. Meillä on talossa lukematon määrä servereitä joille ei ole koskaan tehty mitään huoltotoimenpiteitä. Ei edes päivityksiä. Ne vaan hurisee vuodesta toiseen ja toimii. Onko sitten päivityksillä, levyneheytyksellä tietokantojen purgeilla tms toimenpiteillä merkitystä. Ilmeisesti ei. Ei ainakaan kaikessa käytössä. Varmasti lukemattomissa organisaatioissa on valtavat määrät servereitä joille ei ole tehty mitään sen jälkeen kun ne on saatu kerran "toimimaan". Jos se toimii, älä korjaa sitä. On ainakin hyvä ohje siellä missä resursseista on muutenkin jatkuvasti pulaa.

Voisit kokeilla laittaa nuo pienet tiedostot yhdelle omalle osiolle ja isot tiedostot toiselle omalle osiolle. Osiot voit halutessasi säätää käyttötarkoitukseesi sopivaksi. man mksf.ext3 auttaa. Voit sitten kertoa voititko jotain. Näin voit osoittaa levysi fragmentoitumisesta johtuvan haitan. Jos optimoit tiedostojärjestelmäsi, saatat saada muutakin pientä etua nykytilanteeseen verrattuna.

Tuohon tulokseen tultiin aika nopeasti täälläkin. Eli pieni temp osio noille pienille tiedostoille, josta ne siirretään sitten esim kerran vuorokaudessa zip pakettiin ja talteen isommalle osiolle. Onkin hyvä kysymys miksi järjestelmämme säästää nuo tiedostot kun kerran aivan vastaava data on tietokannassa. Lisäksi vastaava data on vielä (joskin hankalammin) saatavissa myös lähdejärjestelmästä uudelleen. Sinänsä noiden tiedostojen säästämiselle ei pitäisi olla muuta syytä kuin että niiden uudelleen prosessointi virhetilanteessa on helppoa kun ne löytyy palvelimen levyltä. Noita pieniä 1-4 kt XML tiedostoja tulee 10-50 tuhatta kappaletta vuorokaudessa.

Oma käyttöni on niin tavallista, etten jaksa noin pieniä optimointeja tehdä.

Juu. Kuten todettu, täälläkin on valtava määrä NAS / muita verkkolevy / järjestelmä palvelimia joita ei ole koskaan "huollettu", kun ei sillä ole käytännössä mitään merkitystä. Tuossa em. palvelimessa vain oikeasti tuli fragmentoituminen isoksi ongelmaksi. Varsinkin kun noita pikkutiedostoja siivottiin vasta sitten pois kun levy oli niin täynnä että tuli 1 gigan levytila varoitus. (järjestelmässä on tera levyä 3x500GB Raid5) Sekä systeemi on pyörinyt vuosi kausia, jolloin fragmentoitumsiella on hyvää aikaa rakentua. Samoin järjestelmän tietokannasta tehdään suuria yhtäjaksoisia datalukuja erilaisia analyysejä varten. Tuolloin tuhoton fragmentoituminen todellakin näkyy ja kuuluu. Jo yksi prosessi saa levy I/O:n täysin tappiin.

Aika monesti NCQ hidastaa työpöytäkäytössä käyttöä hieman tai sillä ei ole vaikutusta. Uusimmilla kovalevyillä valmistajat ovat saaneet muutaman prosentin eron yleensä NCQ:n hyväksi. Eroja löytyy palvelinkäytössä kyllä enemmänkin, tosin silloin varmaan usein 10-15krpm SCSI-levyt voivat olla enemmän tarpeen.

Aivan. NCQ:n ja levypuskureidenkin osalta on olennaista se, että levyluku(a) on tarpeeksi jonossa. Eli jos käyttis / sovellus pyytää lukemaan sitä ja sitten sen jälkeen tätä. Niin NCQ:sta ei ole mitään hyötyä vaan luvut pitäisi saada "rinnakkain" sisään jotta niistä muodostuisi NCQ tasolle jonoa. Olenkin huomannut että Linuxissa mm. levy puskurit (?) ovat optimoitu läpäisyn ei vasteajan osalta. Eli jos on yksi prosessi joka lukee levyltä 1 ja kirjoittaa levylle 2. Tämä tuntuu hidastavan hyvin merkittävästi kaikkia prosesseja jotka tekevät mitä tahansa pientä levy I/O:ta. Tarkoittaa sitä että tuota kopionti prosessia käsitellään aika isoina lohkoina. Muuten rinnakkais prosessit pääsisivät paremmin väliin. Saako tätä arvoa muuten säätää jossain? Ainakin Desktop käytössä tuota lohkokokoa voisi pienentää.

Creativen X-Fi-äänikorttien superominaisuudet - "tee MP3:stasi tämän käyrän osoittaman verran paremman kuuloista kuin CD:n ääni" - jjep.

No tästä olen kyllä samaa mieltä, olenkin nauranut noille mainoksille aika raskaasti.

No NCQ ei toki ole vaporwarea, ja tukeakin sille kernelissä on. Kuten kaikissa avoimen lähdekoodin projekteissa, tuki kytketään päälle kun sillä on riittävästi merkitystä jollekin niin että koodi saadaan kunnolla valmiiksi. Voi olla että kaikista näistä NCQ:n ongelmista ja lähes häviävän pienistä hyödyistä (poislukien SATA-levyjen palvelinkäyttö) johtuen yhtäkään aihetta tuntevaa kehittäjää ei asia vain ole kiinnostanut riittävästi. SATA-levyjen palvelinkäytön hyötyjen takia luulisi tosin aiheuttavan riittävää kiinnostusta.

Jep. Tuo riittävämerkitys onkin hyvä kysymys. Se on niin sektorista ja resursseista kiinni. Kiinnostaako F1 tallia jos joku esittelee tekniikan joka maksaa miljoonan ja saa auton 1% nopeammaksi? No taatusti kiinnostaa. Mutta ehkä kaikkialla muualla ei ole vastaavaa mielenkiintoa marginaaliseen parannukseen.

Itse olin kyllä tosiaan siinä käsityksessä että NCQ:ta tuetaan jo useimmilla SATA-ohjaimilla, kuten kaikilla AHCI-standardia noudattavilla. Esim. http://linux-ata.org/software-status.html#tcq sanoo NCQ:sta "#3 is supported by libata, for most hardware and devices that support NCQ."

Ubuntuforumissista luettuna, tuo vaatii jonkun testikernelin ja siihen patchit. Eli ei ole vakio-ominaisuutena käytössä. Järjestelmä kyllä tunnistaa NCQ:n ja osaa näyttää sen olemassa olon, mutta se ei ole aktiivisena.

Hieman jäi mietityttämään se, että miksi NCQ lisää latenssia. Ainakaan teroiassa sen ei pitäisi, mutta totuushan voi olla ihan jotain muuta. Esimerkiksi huono implementointi / yhteensopivuus sekä rauta että softa-ohjaimien kanssa tms.

Toinen missä tämä "riittävää hyötyä" ilmiö näkyy hyvin on mielestäni moniprosessorisille järjestelmille sopivat ohjelmistot. Moni ohjelmisto voitaisiin laittaa tukemaan moniprosessorisia järjestelmiä, mutta silti ei ole vielä toistaiseksi nähty sille tarvetta. Eli kehittäjien mielestä kustannus / hyöty analyysin pohjalta se ei vaan kannata. Rinnastamisen myötä myös riski hämäriin bugeihin kasvaa aika kiitettävästi. Jos kerran perussoftan toimimaan saaminen on jo vaakalaudalla, kuka haluaa lähteä tekemään hyvin multithreadaavaa versiota?

Vielä parina referenssinä mainittakoon esim uTorrentin Super-Seed ja eMulen "rarest block first" toiminnot. Kummallakaan toiminnolla ei saavuteta varmaa hyötyä, mutta ainakin tietyissä tilanteissa kummastakin on osoitettavissa olevaa hyötyä. Muistan kuinka eDonkey2000 kehittäjät pitkään taisteli rarest block first featurea vastaan, kun ei siitä ole mitään hyötyä. Tässä talossa törmään myös jatkuvasti vastaavaan ongelmaan. Jotain parannusta ei haluta tehdä, sen takia että sillä ei ole mitään merkitystä. Toimiihan se. Vastustettiinhan kaikkia auton turvaparannuksia ja turvavarusteitakin hyvin pitkään autoteollisuuden toimesta. Asiat eivät aina ole valitettavasti ihan yksinkertaisia.

Kiitos Stroragereviewin linkistä, tutustun sisältöön. Tuollahan se lukee suoraan, parhaimmillaan NCQ:n käyttö parasi suorituskyvyn kaksinkertaiseksi (ilman NCQ:ta tulos oli 51% huonompi), kun levyltä luettiin hajallaan olevia tietoja. Eli juuri tilanteessa jossa esimerkiksi yksi iso tiedosto on päässyt fragmentoitumaan pahasti. En sanoisi tuota lainkaan merkityksettömäksi asiaksi. - Kiitos referenssistä. Tuo siis parhaassa tapauksessa. Monissa tilanteissa vaikutusta ei ollut lainkaan tai se oli lievästi negatiivinen. Mutta mielestäni siis järjestelmissä joissa on levy I/O rajoitteisuutta niin NCQ kannattaa laittaa päälle. Koska mahdolliset hyödyt kuormituksessa ovat isommat kuin haitat.

Vista / NTFS asiaa: Huomasin tänään että jostain aivan käsittämättömästä syystä esim Vista tuntuu fragmentoivan tiedostoja täysin tolkuttomasti. Latasin tuossa kasan 21 kilotavun sähköposteja. Jokainen tiedosto oli 3-4 fragmentissa. Samoin hankemiston indeksi joka oli 40 kiloa oli mukavasti 10 fragmentissa. Eli kaikki on levällään kuin jokisen eväät.

NCQ referenssi: http://www.storagereview.com/500.sr?page=0%2C6

Se sitten osaako sovellukset esim hyödyntää jonoja on ihan toinen kysymys. Eli mennään samaan kategoriaan kuin multicore tuen kanssa. Fiksusti tehty tietokanta sovellus esim osaa hyödyntää tuota jonoa, vaikka sisään tulisikin yksi requesti. Voihan sen aina forkata ja pilkkoa pienempiin osiin. Klassisen tyhmästitehtyjen sovellusten kanssa hyödyt erilaisista rinnastamisista tai pipelineistä jää täysin olemattomiksi. Pari kaveria tekee softia isoille klustereille, niissä on kyllä mietittävä tarkkaan miten prosessit suunnittelee. Ettei 1023 konetta jauha tyhjää kun yksi jumittaa.

[Ux64]

Uusimman TrueCryptin dokumentoinnissa manitaan muute että Pipelined (parallel NCQ requests) lisää suorituskykyä jopa 100%.

Lukupyyntöjä siis tungetaan jonoon eikä vasta sitten kun on saatu vastaus edelliseen. Ihan perus optimointi, monessako softassa on käytössä?

Josta tuli muuten mieleen että ainakin MySQL ja Hibernate paketin kanssa ihmettelin miksi joskus kyselyitä on hirveä määrä auki rinnakkaisena vaikka kutsuja lähetetään yksitellen. Se on hyvä että joku rajapinta osaa rinnastaa kyselyt, vaikka niitä tehtäisiinkin vain yksi kerrallaan.

Riippuu sitten alustasta onko tuosta hyötyä vai haittaa. Vanha viisaushan sanoo että rinnastaminen vain hidastaa prosessia. Silloin kun resurssit eivät ole jaettavissa. Joissain tapauksissa vielä seektime ja fragmentoituminen (joko datan tai data lukupyyntöjen vuoksi) ovat hyvin ratkaisevia.

Kokeileppa joskus kopioida vaikka dvd levyltä tiedostot rw levylle siten että rinnastat prosessin. Rinnakkais suorituksen aika kasvaa helposti yli kymmenen kertaiseksi siihen verrattuna, että olisit suorittanut ne peräkkäin.

[kriitikko]

Uusimman TrueCryptin dokumentoinnissa manitaan muute että Pipelined (parallel NCQ requests) lisää suorituskykyä jopa 100%.

Lukupyyntöjä siis tungetaan jonoon eikä vasta sitten kun on saatu vastaus edelliseen. Ihan perus optimointi, monessako softassa on käytössä?

Kiitos tiedoista, mutta eikö olisi kätevämpää, että kysyisit noita kysymyksiä suoraan kehittäjiltä? Asiallinen kysymys esimerkiksi jollekin seuraavista postituslistoista Kernel, MySQL, niin saat varmasti asiallisia vastauksia.

Kerro kun olet pistänyt postia, niin seuraillaan miten keskustelu kehittyy.