- Liittynyt
- 21.06.2017
- Viestejä
- 7 406
No nyt alkoi vihdoin nassille kirjoittelu sujumaan niinkuin halusin. Otti se aikaa ja monen monta yritystä ja erehdystä.
Tuossa kuvassa siis kirjoitellaan 40G tiedostoa ja nopeus pysyy periaatteessa verkon maksimissa kokoajan mitä 2,5G verkko antaa myöten. Aiemmin toi sahasi jossain maksimin ja 100MB/s välillä koska HHD:lle ei vaan toi kirjoitus suju niin sukkelaan.
Alkuperäinen ajatus oli laittaa puoli teraa nvme pintaa joka on raid1 tuohon cacheksi ja sitä lähdin toteuttamaan. LVM cache oli homman nimi jolla tätä operaatiota vein etiäpäin koska en halunnut alkaa koko systeemiä rakentaa nollasta. Nopeasti huomasin että LVM:lle on pari eri cache vaihtoehtoa jotka käyttää deviuce mapper kikkareita, elikkä dm-cache ja dm-writecache. Lähdin liikkeelle dm-cachen kanssa kun mielsin sen monipuolisemmaksi.
Sain homman toimimaan mutta se ei toiminut kuten olin toivonut. Kirjoitukset oli ihan samaa paskaa kuin ennenkin vaikka käytössä oli writeback cache.
Lopulta kun tarpeeksi lueskeliu internettiä ja pohdiskeli niin päädyin siihen tulokseen että vaikka toi dm-cache writeback tilassa tekeekin cachea niin lukiessa kuin kirjoittaessa, niin se kirjoittaessa tapahtuva cache tapahtuu ainoastaan jos data on jo ylennetty sinne cacheen. dm-cachen toinen toimintamoodi on writethrough joka siis oli poissa laskuista, se ei kirjoituksia cacheta ollenkaan.
Seuraavaksi sitten tuli eteen cache tyypin vaihto tuohon dm-writecacheen. Se ei siis cacheta lukuja ollenkaan vaan toimii pelkästään kirjoituscachena. Tässä vaiheessa sitten tulikin mieleen että eipä sitä cachea ole järkevää puolta teraa laittaa ja päädyin että laitetaan 100G. Toi cache on vielä siitä erikoinen että sen koko vaikuttaa samalla siihen että paljonko se haukkaa muistia. Toi 100G haukkasi muistista 2G, joten senkin takia puol teraa olisi ollut hölmöä touhua kun purkissa ei ole kuin 16G muistoa.
Eihän toikaan suoriltaan lähteny toimimaan niin kuin toivoin, mutta muutakia optioita muuttamalla sain sen nyt ainakin pikaisten testien kanssa toimimaan pitkälti niin miten haluan.
Lisäksi tää LBA/block size 512/4096 sekoilu aiheutti asiaan omat murheensa. Päätin jo aikaa sitten että 512 saa jäädä, mutta yllätävän sitkeessä se edelleen on. Molemmat nvme:t formatoin 4096 LBA:lle, mutta kovalevyt on kaikki 512 loogisella koolla mutta fyysinen on 4096, eikä noissa laikoissa voi sitä vaihtaa. Ja en puhu mistään filesystem tason formatoinnista vaan tästä: Switching your NVME ssd to 4k - Bjonnh.net tätä myös advanced format nimellä kutsutaan. Advanced Format - Wikipedia
LVM alkoikin heti natkuttaa siitä että samaan volume grouppiin ollaan nyt laittamassa 512 ja 4096 block size asemia ja tämä ei käy. Syykin sille on selvä, noiden kanssa kun alkaa sekoilla ja sekottamaan sopivassa paikkaa niin datalle voi sanoa hyvästit.
LVM conffiin voi laittaa ohituksen jonka päädyin tekemään koska mulla loppupelissä itse filesystem käyttää 4096 block size jolloin oman päättelyn ja interwebin lukemisen perusteella ongelmaa ei pitäisi olla.
Tuossa kuvassa siis kirjoitellaan 40G tiedostoa ja nopeus pysyy periaatteessa verkon maksimissa kokoajan mitä 2,5G verkko antaa myöten. Aiemmin toi sahasi jossain maksimin ja 100MB/s välillä koska HHD:lle ei vaan toi kirjoitus suju niin sukkelaan.
Alkuperäinen ajatus oli laittaa puoli teraa nvme pintaa joka on raid1 tuohon cacheksi ja sitä lähdin toteuttamaan. LVM cache oli homman nimi jolla tätä operaatiota vein etiäpäin koska en halunnut alkaa koko systeemiä rakentaa nollasta. Nopeasti huomasin että LVM:lle on pari eri cache vaihtoehtoa jotka käyttää deviuce mapper kikkareita, elikkä dm-cache ja dm-writecache. Lähdin liikkeelle dm-cachen kanssa kun mielsin sen monipuolisemmaksi.
Sain homman toimimaan mutta se ei toiminut kuten olin toivonut. Kirjoitukset oli ihan samaa paskaa kuin ennenkin vaikka käytössä oli writeback cache.
Lopulta kun tarpeeksi lueskeliu internettiä ja pohdiskeli niin päädyin siihen tulokseen että vaikka toi dm-cache writeback tilassa tekeekin cachea niin lukiessa kuin kirjoittaessa, niin se kirjoittaessa tapahtuva cache tapahtuu ainoastaan jos data on jo ylennetty sinne cacheen. dm-cachen toinen toimintamoodi on writethrough joka siis oli poissa laskuista, se ei kirjoituksia cacheta ollenkaan.
Seuraavaksi sitten tuli eteen cache tyypin vaihto tuohon dm-writecacheen. Se ei siis cacheta lukuja ollenkaan vaan toimii pelkästään kirjoituscachena. Tässä vaiheessa sitten tulikin mieleen että eipä sitä cachea ole järkevää puolta teraa laittaa ja päädyin että laitetaan 100G. Toi cache on vielä siitä erikoinen että sen koko vaikuttaa samalla siihen että paljonko se haukkaa muistia. Toi 100G haukkasi muistista 2G, joten senkin takia puol teraa olisi ollut hölmöä touhua kun purkissa ei ole kuin 16G muistoa.
Eihän toikaan suoriltaan lähteny toimimaan niin kuin toivoin, mutta muutakia optioita muuttamalla sain sen nyt ainakin pikaisten testien kanssa toimimaan pitkälti niin miten haluan.
Lisäksi tää LBA/block size 512/4096 sekoilu aiheutti asiaan omat murheensa. Päätin jo aikaa sitten että 512 saa jäädä, mutta yllätävän sitkeessä se edelleen on. Molemmat nvme:t formatoin 4096 LBA:lle, mutta kovalevyt on kaikki 512 loogisella koolla mutta fyysinen on 4096, eikä noissa laikoissa voi sitä vaihtaa. Ja en puhu mistään filesystem tason formatoinnista vaan tästä: Switching your NVME ssd to 4k - Bjonnh.net tätä myös advanced format nimellä kutsutaan. Advanced Format - Wikipedia
LVM alkoikin heti natkuttaa siitä että samaan volume grouppiin ollaan nyt laittamassa 512 ja 4096 block size asemia ja tämä ei käy. Syykin sille on selvä, noiden kanssa kun alkaa sekoilla ja sekottamaan sopivassa paikkaa niin datalle voi sanoa hyvästit.
LVM conffiin voi laittaa ohituksen jonka päädyin tekemään koska mulla loppupelissä itse filesystem käyttää 4096 block size jolloin oman päättelyn ja interwebin lukemisen perusteella ongelmaa ei pitäisi olla.