Kirjoittaja Aihe: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU  (Luettu 15181 kertaa)

Roberto

  • Käyttäjä
  • Viestejä: 185
    • Profiili
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #20 : 26.06.20 - klo:21.12 »
Kirjoitan tätä nyt Ubuntu koneessa. Nämä voivat käyttäytyä eri tavalla muissa järjestelmissä.
Jos /home on omalla osiollaan, niin fstrim.service asetuksissa se voidaan ohittaa oletuksena.
Tämän voi muttaa asetuksella: ProtectHome=yes vaihdetaan muotoon ProtectHome=read-only
Sitten:
Koodia: [Valitse]
sudo systemctl daemon-reload
sudo fstrim -va
Dell OptiPlex 7470 (All in One), i5-9500 (6) @ 4,4 GHz, 32 Gt DDR4, Samsung 980 (PCIe NVMe M.2 SSD 2280) 500 Gt
Jäähyllä olevat: Amiga 500, C64

raimo

  • Käyttäjä
  • Viestejä: 4269
  • openSUSE Tumbleweed
    • Profiili
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #21 : 26.06.20 - klo:23.07 »
Kirjoitan tätä nyt Ubuntu koneessa. Nämä voivat käyttäytyä eri tavalla muissa järjestelmissä.
Jos /home on omalla osiollaan, niin fstrim.service asetuksissa se voidaan ohittaa oletuksena.
Tämän voi muttaa asetuksella: ProtectHome=yes vaihdetaan muotoon ProtectHome=read-only
Sitten:
Koodia: [Valitse]
sudo systemctl daemon-reload
sudo fstrim -va

Miksi /home pitäisi ohittaa, monella se on se suurin tilanviejä. Tosin meitä joilla on erillinen iso data-levy (HDD) lienee aika paljon.
Tietä käyden tien on vanki. Vapaa on vain umpihanki.
Aaro Hellaakoski

Postimies

  • Käyttäjä
  • Viestejä: 2644
    • Profiili
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #22 : 27.06.20 - klo:04.34 »
Miksi /home pitäisi ohittaa, monella se on se suurin tilanviejä. Tosin meitä joilla on erillinen iso data-levy (HDD) lienee aika paljon.
Home usein perinteisellä levyllä ja sen järjestely ei juuri nopeuta systeemiä.
Trim voidaan asettaa myös fstab-tiedostossa, mutta käyttöä ei suositella.
Esim rivi /dev/sda1  /           ext4  defaults,discard   0  1
niin trim on jatkuvasti päällä.
Kaikki tiedostojärjestelmät eivät tue trimmiä.
Nopeushyöty on pieni. Varsinkin jos muistia riittävästi.
Vähän kuin Windowssin levyn eheytys - sen jälkeen kone
"tuntuu" nopeammalta.
Itsellä pääsi levy täyttymään ja meni aikaa mistähän johtuisi.
Jotkut ohjelmat kirjoittavat yllättävän paljon asetuksia, mutta harvempi poistaa ja
siivoaa levyä. Jo Kodin kansiossa oli liki 20 000 tiedostoa.
Systeemi ei juuri paisu, mutta home kyllä.

Roberto

  • Käyttäjä
  • Viestejä: 185
    • Profiili
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #23 : 27.06.20 - klo:04.35 »
Tarkoitus oli oikeastaan vain sanoa, että se oli tässä Ubuntussa oletuksena ohitettu, vaikka on SSD levyllä.
Syytä tähän voi kysyä Ubuntun kehittäjiltä.
« Viimeksi muokattu: 27.06.20 - klo:05.46 kirjoittanut Roberto »
Dell OptiPlex 7470 (All in One), i5-9500 (6) @ 4,4 GHz, 32 Gt DDR4, Samsung 980 (PCIe NVMe M.2 SSD 2280) 500 Gt
Jäähyllä olevat: Amiga 500, C64

Postimies

  • Käyttäjä
  • Viestejä: 2644
    • Profiili
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #24 : 27.06.20 - klo:10.14 »
Tarkoitus oli oikeastaan vain sanoa, että se oli tässä Ubuntussa oletuksena ohitettu, vaikka on SSD levyllä.
Syytä tähän voi kysyä Ubuntun kehittäjiltä.
Itsellä /home kansiossa on lähinnä asetukset ja joitain työjuttuja jotka hyötyvät SSD:n nopeudesta.
Tässä koneessa ei ole ikinä ajettu trimmiä ja en ole huomannut hidastumista. Tosin käyttö median
toistoa ja satunnaista netin selailua. Ubuntukin vielä 16. Ainoa hidastuminen on sammutuksen kesto.
Ei haittaa kun muutenkin pistän koneen sammumaan joskus yöllä shutdown komennolla.

Tomin

  • Palvelimen ylläpitäjä
  • Käyttäjä / moderaattori+
  • Viestejä: 11481
    • Profiili
    • Tomin kotisivut
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #25 : 27.06.20 - klo:16.41 »
Tuosta /var/tmp:in siirtämisestä keskusmuistiin mainitsisin sen verran, että FHS:n mukaanhan se sisältää käynnistyksen yli pysyviä väliaikaistiedostoja. Ajatuksena lienee (en tarkistanut!), että ohjelmat voivat luoda sinne sellaiset väliaikaistiedostot, joiden luominen kestää erityisen kauan tai vaatii erityisen paljon lasketatehoa tai muita resursseja. Itse en ole /var/tmp:ä tai lokeja siirtänyt pois levyltä. Uskon nykyisten (laadukkaiden) SSD-levyjen kestävän käyttöä aivan tarpeeksi kauan. Toisaalta ostin kerran halvan levyn (joku yleinen Sandforce:n ohjaimella oleva) ja se lakkasi kokonaan toimimasta kesken käytön. Sekään ei johtunut liiallisesta kirjoitusmäärästä vaan syynä liene ohjaimessa tai laiteohjelmistossa ollut virhe, joka nyt vain sattui iskemään kohdalleni. Sain takuuvaihdossa uuden levyn. Sen jälkeen olen kuitenkin pysytellyt Samsungeissa ja halvempaa tarvitessa Kingstoneissa (ja esim. Intelinkin voisin ostaa), vaikka niistäkin löytyy omat vialliset tapauksensa. :D

SSD-levyjen laiteohjelmistoissa on ollut toisinaan ollut bugeja trimin kanssa ja sen vuoksi kernelistäkin löytyy mallikohtaisia korjauksia. Tuo voi olla myös syy jossain jakelussa jättää trim oletuksena pois päältä, koska noilla bugeilla on joskus valitettavasti tapana hävittää tietoja. Yleistä se ei onneksi taida olla tai näkisimme sellaista useammin täälläkin.
Automaattinen allekirjoitus:
Lisäisitkö [RATKAISTU] ketjun ensimmäisen viestin aiheeseen ongelman ratkettua, kiitos.

Postimies

  • Käyttäjä
  • Viestejä: 2644
    • Profiili
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #26 : 28.06.20 - klo:13.06 »
Olisi kiva saada joku esimerkki jossa  /var/tmp siirto keskusmuistiin oikeasti nopeuttaisi. SSD-levyt kestäviä, mutta kummasti edelleen elää tuo legenda etteivät kestäisi paljon kirjoittamista. Kiinasta saa halpoja tikkujakin jotka muistuttuvat alkuperäistä, mutta ominaisuudet eivät. Käyttöarvo voi olla olematon. Kunnon SDD levy kestää. Nykyiset osiointiohjelmat osannevat tehdä työnsä oikein. Joskus piti laskea sektoreita ja poistaa dos-yhteensopivuus, että alignment (mitähän suomeksi) meni oikein. Silläkin merkitystä miten levy osioitu kun sektoreiden koot vaihelevat. Juttua vaikka https://www.thomas-krenn.com/en/wiki/Partition_Alignment_detailed_explanation.

Paljonko trim oikeasti nopeuttaa konetta itselle on jäänyt epäselväksi. Jos paljon pieniä tiedostoja. Vaikka muutama 100 000 niin kirjoitus kestää huomattavasti kauemmin. Varsinkin tikulle helvetillisen kauan.  Mutta harvalle lienee moiselle tarvetta. Suuri määrä pieniä tiedostoja voi kyykyttää koneen, vaikka datamäärä olisi kohtuullinen. Jos syteemiä ajetaa hitaalta medialta väliäikaistiedostojen siirto keskumustiin nopeuttaa paljon. Esim C käännös ei valttämättä edes onnistu tikulla.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #27 : 11.11.20 - klo:17.25 »
Tämän voi tarkistaa Ubuntussa näin:

Koodia: [Valitse]
systemctl status fstrim.timer

Kiitos tästä. Olinkin juuri tutkimassa miksi kone aina silloin tällöin jumittaa aivan järjettömästi buutin yhteydessä. Aloin epäilemään discardia, koska se näytti just siltä ja sitähän se sitten oli. En vain ollut ihan varma minkä mekanismin kautta tuo ongelma syntyy.

juyli

  • Käyttäjä / moderaattori
  • Viestejä: 1200
    • Profiili
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #28 : 13.11.20 - klo:00.22 »
Olinkin juuri tutkimassa miksi kone aina silloin tällöin jumittaa aivan järjettömästi buutin yhteydessä.
Eikö käynnistettäessä näe, mitä koneella tapahtuu?
Poistan grubista määritykset GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
/boot/grub/grub.cfg
/etc/default/grub
tai taon ESC-näppäintä.
Yleensä koneen käynnistyksen hidastelu johtuu siitä, että järjestelmä tarkistaa levyosion (tai useamman).
Levyosioiden tarkistus on mielestäni hyödyllinen ominaisuus, vaikka se voi oleellisesti hidastaa käynnistymistä.

Sami Lehtinen

  • Käyttäjä
  • Viestejä: 754
  • Techie
    • Profiili
    • Sami Lehtinen
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #29 : 14.11.20 - klo:10.35 »
Eikö käynnistettäessä näe, mitä koneella tapahtuu?
Poistan grubista määritykset GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
/boot/grub/grub.cfg
/etc/default/grub
tai taon ESC-näppäintä.
Yleensä koneen käynnistyksen hidastelu johtuu siitä, että järjestelmä tarkistaa levyosion (tai useamman).
Levyosioiden tarkistus on mielestäni hyödyllinen ominaisuus, vaikka se voi oleellisesti hidastaa käynnistymistä.

No tuon discardin kurjuus jujutus onkin siinä, että se ei näy tuossa logissa mitenkään olennaisesti, eikä se ole sellainen taski joka olisi blocking tyyppiä. Sehän käynnistyy joka bootissa. Mutta milloin se jumittaa järjestelmään ja milloin ei riippuu sitten prosessin sisällä olevasta ajastimesta. Se vaan jää taustalle pitkäksi aikaa hidastamaan konetta, joten siksi sitä ei ollut niin helppoa paikantaa. Olen ihan varma, että suurin osa ongelmasta kärsivistä ei ikinä hiffaa mikä tuon aiheuttaa, sen verran jekusti se on toteutettu, varsinkin kun siinä on vielä joskus viivettä ennen kuin se alkaa.

Postimies

  • Käyttäjä
  • Viestejä: 2644
    • Profiili
Vs: Ubuntu 20.04 asentaminen SSD:lle RATKAISTU
« Vastaus #30 : 15.11.20 - klo:13.59 »
Jos koneessa useampi käyttöjärjestelmä väärät aikaleimat aiheuttavat myös levyntarkistuksen.