Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Asentaminen ja käyttöönotto => Aiheen aloitti: JaniAlander - 01.06.20 - klo:16.00
-
Onkos siinä erityistä huomioitavaa vai ovatko oletusasetukset ns. järkevät. Meinaan tässä ostaa toisen SSD levyn pöytäkoneeseen ja tarkoitus olisi Ubuntu tai Kubuntu 20.04 siihen pistää. Nykyinen SSD on varattu Windows 10:lle.
-
Itse asennuksen aikana ei tarvitse tehdä mitään valintoja SSD levyyn liittyen, esim. TRIM toimii.
Mutta tarkista ennen asennusta BIOS asetuksista että SSD levyn asetuksena on AHCI eikä IDE.
Windows levyn asetusta ei kannata muuttaa tai voi tulla sininen tervehdys (ajurit?).
Tässä koneessa esim. /tmp on keskusmuistissa (Muistia koneessa on 12GiB) ja se säästää levyä.
-
Mikähän se nykyinen kanta on tuohon levynkirjoituksen vähentämisen tarpeeseen? Taitavat jo olla aika kestäviä nuo SSD:t.
Olen silti tehnyt rutiininomaisesti aina uuden asennuksen jälkeen tuon kirjoituksen vähentämisen. En ole huomannut haittavaikutuksia, jos en hyötyjäkään. Yksi bad-sektori on SSD:ssä silti nytkin; tuon Levyt ohjelman mukaan.
Olen tehnyt näin:
Levynkäytön vähentäminen SSD:n kulumisen vähentämiseksi. Siirretään tilapäistiedostot levyn asemasta RAM.iin. (Ne sitten myös katoavat joka sammutuksessa):
Ensin fstabiin lisätään rivejä, avaa tiedosto:
sudo -i mousepad /etc/fstab
Lisää sen loppuun seuraavat rivit:
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
mpfs /var/tmp tmpfs defaults 0 0
Muista tallettaa mousepad.
Huom! /var/log/apt kansio pitää luoda joka käynnistyksen yhteydessä tai tulostuu virheitä ruudulle (esteettinen haitta). Sitä varten voidaan luoda käynnistysskripti:
Ensin tehdään tiedosto:
sudo -i mousepad /etc/init.d/fix_apt_log_error.sh
Sitten siihen sisältö:
mkdir -p /var/log/apt
Talleta mousepad.
Anna käynnistysoikeus:
sudo chmod +x /etc/init.d/fix_apt_log_error.sh
Valmis.
Nyt voit siirtää myös Firefoxin tilapäistiedostot RAM.ille, vähentää myös selauksen nykimistä:
Kirjoita Firefoxin osoitepalkkiin:
about:config
Vastaa kysymykseen ”kyllä, olen huolellinen”.
Klikkaa tyhjää kohtaa hiiren oikealla.
Valitse pudotusvalikosta:
Uusi – Merkkijono.
kirjoita merkkijonon nimeksi:
browser.cache.disk.parent_directory
ja arvoksi:
/tmp
Valmis.
-
Kiitoksia neuvoista. :)
-
/tmp tai /var/tmp voi tulla hyvin suureksikin ja miettisin niiden siirtämistä keskusmuistiin. Levyn kulumisesta ei minusta tarvitse huolestua.
Jos ei ikinä työskentele isojen tiedostojen kanssa tai käännä isoja ohjelmia niin /tmp voi olla keskusmuistissa. Kun muisti loppuu kone hyytyy pahasti.
/tmp puhdistetaan kuitenkin systeemin puolesta kun kone käynnistetään uudestaan. Logrotate puhdistaa /var/log kansiota.
trim ei ole käytössä kaikilla levyillä automaattisesti. Voihan sen ajaa välillä manuaalisesti. Nopeushyöty melko pieni.
Joskus voi käydä niin että /var/log täyttää levyä. itselle kävi niin yhdessä asennuksessa kun lirc taustalla lokitti erroria hirmuisesti.
du komennolla voi välillä kurkata onko kansioiden koot järkeviä. Jos asennus kohtuu pienellä levyllä virheellisesti toimivan ohjelman
huomaa nopeammin.
-
Vähän mietin että mounttaisin tmp:n ja var:in vanhalle levylle. Kone ottaa siitä kyllä nopeustappiota...
-
Jos pöytäkone ei ole kovin vanha, niin saat varmaankin lisättyä muistia helposti jos sitä ei ole tarpeeksi.
Silloin temppi kansiot keskusmuistiin. Kokoa voi myös rajoittaa.
Oma esimerkki:
tmpfs /tmp tmpfs defaults,noatime,size=1G,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,size=512M,mode=1777 0 0
Näillä on menty jo pitkään ja mennään jatkossakin.
Noiden kokoa voi säädellä sitten tarpeen mukaan.
-
No tuo 24 gigaa on tähän asti riittänyt....kaipa se riittää tuollaisellakin virityksellä.
-
Oma esimerkki:
tmpfs /tmp tmpfs defaults,noatime,size=1G,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,size=512M,mode=1777 0 0
Näillä on menty jo pitkään ja mennään jatkossakin.
Noiden kokoa voi säädellä sitten tarpeen mukaan.
Itsellä on /var/tmp 4G koska pistän ohjelmien käännösten väliaikaistiedostot sinne. Jos ison tiedoston lähettää ssh:lla niin sen salaus vaatii myös tilaa. 4G ei riitä enää isoille ohjelmille. Joskus pitää kasvattaa jopa 9G. Kuvien editointi voi vaatia myös hetkellisesti paljon tilaa. Harvempi tosin kasaa isoja panoraamoja.
-
No tuo 24 gigaa on tähän asti riittänyt....kaipa se riittää tuollaisellakin virityksellä.
Kyllä tuolla muistimäärällä (toistaiseksi varmasti pärjää). Fedora jo oletuksena varaa muistista tmpfs:lle puolet muistista:
total used free shared buff/cache available
Mem: 8048084 746552 5422116 170740 1879416 6864636
Tiedostojärjestelmä 1K-lohkot Käyt Vapaana Käy% Liitospiste
devtmpfs 4004576 0 4004576 0% /dev
tmpfs 4024040 64488 3959552 2% /dev/shm
tmpfs 4024040 1584 4022456 1% /run
...
tmpfs 4024040 8 4024032 1% /tmp
tmpfs 804808 36 804772 1% /run/user/XXXXJoskus aikanaan totesin tuon /tmp -hakemiston muistissa jäänee liian pieneksi, kun ohjelma (K9Copy) käytti tmp-muistia liian"tehokkaasti".
Toki 24Gt ei tuolloinkaan olisi tuottanut ongelmia (jos tmpfs on tuollaiset 12 Gt).
-
Moi! Tilasin just Samsung Evo 860 512 GT SATA3 SSD levyn. Mulla on home osio omalla partitiolla vanhalla hdd levyllä ja mietin tässä, että onko puhdas asennus järkevin tapa siirtää Ubuntu 20.04 ssd levylle? Samsung tarjoaa levykloonaus ohjelman mutta tsekkasin sen ja näytti olevan wintoosalle tehty vain.. Osaako se kloonata ext4 levyn vai miten noi kloonaus softat yleensä toimii?
EDIT: Äh, ei kai tiedostoformaatilla ole väliä, kloonaus tekee imagen, on siellä mitä sisältöä tahansa (?).
Vai kannattaako vaan kiltisti tehdä puhdas asennus?
Ja toi tmp osio RAM muistiin on mielenkiintoinen juttu. Mulla on 8Gt RAM:ia, miten toi /tmp RAM muistiin kannattaa siis tehdä?
-
Itse tekisin puhtaan asennuksen ja kopsaisin kiintolevytelakan tai USB-SATA adapterin avulla vain tarvittavat kansiot ja tiedostot.
Sain sen käsityksen että myös juuriosio on kiekkolevyllä. Kiekkolevyä en kloonaisi SSD levylle.
tmpfs asetukset riippuvat siitä mitä koneella on tarkoitus tehdä.
Kuten Postimies kertoi, niin on projekteja joissa pitää olla suuremmat asetukset.
Ihan tavalliseen käyttöön 8GiB muistilla riittää aiemmin tässä ketjussa kertomani asetukset.
Tämä on testattu käytännössä vuosien ajan. Tehokäyttö on sitten jo eri asia.
Siis nämä:
tmpfs /tmp tmpfs defaults,noatime,size=1G,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,size=512M,mode=1777 0 0
Muokkaus:
Varmuuskopio ohjelmalla voi myös tallentaa kotikansion tietoja jollekin sopivalle usb-levylle.
Ja palauttaa sitten uuteen järjestelmään.
-
Itse tekisin puhtaan asennuksen ja kopsaisin kiintolevytelakan tai USB-SATA adapterin avulla vain tarvittavat kansiot ja tiedostot.
Sain sen käsityksen että myös juuriosio on kiekkolevyllä. Kiekkolevyä en kloonaisi SSD levylle.
tmpfs asetukset riippuvat siitä mitä koneella on tarkoitus tehdä.
Kuten Postimies kertoi, niin on projekteja joissa pitää olla suuremmat asetukset.
Ihan tavalliseen käyttöön 8GiB muistilla riittää aiemmin tässä ketjussa kertomani asetukset.
Tämä on testattu käytännössä vuosien ajan. Tehokäyttö on sitten jo eri asia.
Siis nämä:
tmpfs /tmp tmpfs defaults,noatime,size=1G,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,size=512M,mode=1777 0 0
Muokkaus:
Varmuuskopio ohjelmalla voi myös tallentaa kotikansion tietoja jollekin sopivalle usb-levylle.
Ja palauttaa sitten uuteen järjestelmään.
Kiitos, näin teen. Ja kiitos myös /tmp ja/var/tmp avustasi.
-
Itse tekisin puhtaan asennuksen ja kopsaisin kiintolevytelakan tai USB-SATA adapterin avulla vain tarvittavat kansiot ja tiedostot.
Sain sen käsityksen että myös juuriosio on kiekkolevyllä. Kiekkolevyä en kloonaisi SSD levylle.
Itse olen kopioinut systeemin ihan cp -a komennolla. Toki osiot ja tiedostojärjestelmät pitää tehdä. Sitten levyliitokset oikein. Kopioinnin jälkeen korjataan fstab ja asennetaan grub uudestaan. Samsssa ajassa asentanee systeemin uudestaan jos eo paljoa muutoksia.
-
Moi vielä! Löysin tällaisen (https://easylinuxtipsproject.blogspot.com/p/ssd.html) kirjoituksen Ubuntu 20.04 asennukseen SSD:lle liittyen. Aika monta eri tapaa tehdä, tarpeista riippuen :)
TRIM (https://easylinuxtipsproject.blogspot.com/p/ssd.html#ID8) säätöä tässä jäin miettimään, jos ei kirjoitakaan /tmp ja /var/tmp RAM:lle. Onko ohjeet kuinka ajantasalla? Ainakin on kirjoitettu 20.04:lle, että sikäli..
-
Moi vielä! Löysin tällaisen (https://easylinuxtipsproject.blogspot.com/p/ssd.html) kirjoituksen Ubuntu 20.04 asennukseen SSD:lle liittyen. Aika monta eri tapaa tehdä, tarpeista riippuen :)
TRIM (https://easylinuxtipsproject.blogspot.com/p/ssd.html#ID8) säätöä tässä jäin miettimään, jos ei kirjoitakaan /tmp ja /var/tmp RAM:lle. Onko nämä kuinka ajantasalla nämä ohjeet? Ainakin on kirjoitettu 20.04:lle, että sikäli..
Hajanaisten muistikuvien mukaan Ubuntu ajaa fstrim:n aika-ajoin. Tämän voisi joku tietäjä varmentaa?
Kaikki distrot ei sitä tee, esim Fedora johon olen rakentanut skriptinpätkän joka sitten ajetaan crontabin kautta kerran viikossa.
-
Tämän voi tarkistaa Ubuntussa näin:
systemctl status fstrim.timer
Muokkaus:
Näistä voi tehdä valintoja tarpeen mukaan, siis vain yksi kerrallaan.
sudo systemctl enable/disable fstrim.timer
sudo systemctl start/stop/restart fstrim.timer
Lisätietoa.
systemctl cat fstrim.timer
systemctl cat fstrim.service
-
Moi vielä! Löysin tällaisen (https://easylinuxtipsproject.blogspot.com/p/ssd.html) kirjoituksen Ubuntu 20.04 asennukseen SSD:lle liittyen. Aika monta eri tapaa tehdä, tarpeista riippuen :)
TRIM (https://easylinuxtipsproject.blogspot.com/p/ssd.html#ID8) säätöä tässä jäin miettimään, jos ei kirjoitakaan /tmp ja /var/tmp RAM:lle. Onko nämä kuinka ajantasalla nämä ohjeet? Ainakin on kirjoitettu 20.04:lle, että sikäli..
Hajanaisten muistikuvien mukaan Ubuntu ajaa fstrim:n aika-ajoin. Tämän voisi joku tietäjä varmentaa?
Kaikki distrot ei sitä tee, esim Fedora johon olen rakentanut skriptinpätkän joka sitten ajetaan crontabin kautta kerran viikossa.
Syytin Fedoraa suotta, sama systeemi siitä löytyy kuin Ubuntussa. Joku kuitenkin on pielessä kun se ei sitä todistettavasti aja.
Pitää tutkia tilannetta.
[raimo@kone-2 ~]$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor pres>
Active: active (waiting) since Fri 2020-06-26 09:42:55 EEST; 6h ago
Trigger: Mon 2020-06-29 00:00:00 EEST; 2 days left
Triggers: ● fstrim.service
Docs: man:fstrim
Jun 26 09:42:55 kone-2 systemd[1]: Started Discard unused blocks once a week.
-
Täällä Ubuntussa näyttää tekevän maanantaisin.
journalctl -u fstrim
Muokkaus:
Ei tarvitse sudo komentoa eteen tässä koneessa, jossakin voi tarvita.
Kuten testi koneessani jossa on Solus MATE 4.1 ja fstrim toimii siinäkin.
-
Täällä Ubuntussa näyttää tekevän maanantaisin.
journalctl -u fstrim
Muokkaus:
Ei tarvitse sudo komentoa eteen tässä koneessa, jossakin voi tarvita.
Kuten testi koneessani jossa on Solus MATE 4.1 ja fstrim toimii siinäkin.
Kiitos komennosta, näyttää se sen tehneen 22. päivä.
Tämä on uusi Fedora-asennus joten pitää seurata käyttäytymistä.
-
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:
sudo systemctl daemon-reload
sudo fstrim -va
-
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:
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.
-
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ä.
-
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ä.
-
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.
-
Tuosta /var/tmp:in siirtämisestä keskusmuistiin mainitsisin sen verran, että FHS:n (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) mukaanhan se sisältää käynnistyksen yli pysyviä väliaikaistiedostoja (https://linux.fi/wiki/Hakemistorakenne#Pakolliset_elementit_2). 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.
-
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.
-
Tämän voi tarkistaa Ubuntussa näin:
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.
-
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ä.
-
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.
-
Jos koneessa useampi käyttöjärjestelmä väärät aikaleimat aiheuttavat myös levyntarkistuksen.