Linux kysymyksiä

[rikn00]

Kun ei keltään löydy viisastenkiveä tuohon hibernate-ongelmaan, niin kysytään sitten toinen kysymys.

Kun selvittelin asennuksen partitiointia ja asetuksia, törmäsin sellaiseen asiaan, että jotkut ilmeisesti "jakavat" linux asennuksen niin, että tekevät home:lle oman partition/sub-volumen(?) muusta järjestelmästä jonkun "erillisten snapshottien" tekemistä varten. Osaako joku selittää miksi? Ja liittyykö tämä juuri Btrfs:ään?

Erillinen /home-osio on siitä kätevä, että voit asentaa käyttöjärjestelmän uudestaan juuriosioon, mutta käyttäjän tiedostot ja asetukset säilyvät /home-osiolla, jos sitä ei alusteta. Asentaessa kannattaa kuitenkin ottaa ensin varmuuskopiot /homesta vaikka olisikon erillienen osio, moka voi olla helppo tehdä. Tuosta btrfs-tapauksesta voin antaa esimerkiksi openSusen, jossa oletuksena juuriosio käyttää btrfs:sää ja sen copy-on-write-ominaisuutta vähän niinkuin "historian" säilyttämiseen tiedostojärjestelmästä. Snapper-ohjelmalla voi helposti palata aikaisempaan snapshottiin tiedostojärjestelmästä. Kätevää jos vaikka päivitys pistää jotain solmuun. Erillinen home-osio on tässä tarpeen, koska tuo "historia" vaatii ihan kohtalaisesti tallenustilaa ja /homella vaikkapa isot videotiedostot aiheuttaisi kohtuutonta kuormaa tallennustilan kannalta. /home-osiolla ei yleensä muutenkaan ole tarvetta tuollaiselle muutosten kumoamiselle - backupit pitää kuitenkin olla erikseen.

 

[TenderBeef]

Erillinen /home-osio on siitä kätevä, että voit asentaa käyttöjärjestelmän uudestaan juuriosioon, mutta käyttäjän tiedostot ja asetukset säilyvät /home-osiolla, jos sitä ei alusteta. Asentaessa kannattaa kuitenkin ottaa ensin varmuuskopiot /homesta vaikka olisikon erillienen osio, moka voi olla helppo tehdä. Tuosta btrfs-tapauksesta voin antaa esimerkiksi openSusen, jossa oletuksena juuriosio käyttää btrfs:sää ja sen copy-on-write-ominaisuutta vähän niinkuin "historian" säilyttämiseen tiedostojärjestelmästä. Snapper-ohjelmalla voi helposti palata aikaisempaan snapshottiin tiedostojärjestelmästä. Kätevää jos vaikka päivitys pistää jotain solmuun. Erillinen home-osio on tässä tarpeen, koska tuo "historia" vaatii ihan kohtalaisesti tallenustilaa ja /homella vaikkapa isot videotiedostot aiheuttaisi kohtuutonta kuormaa tallennustilan kannalta. /home-osiolla ei yleensä muutenkaan ole tarvetta tuollaiselle muutosten kumoamiselle - backupit pitää kuitenkin olla erikseen.

Kiitoksia vastauksesta! Selvisi jotain mutta myös lisäsi kysymyksiä.

1) Onko tuo snapshot Btrfs:ssä oletuksena käytössä?

1b) Tarkoititko, että sitten /home käyttäisi jotain muuta kuin Btrfs:ää? Esim. EXT4? Vai saako Btrfs:ssä sen CoW:in pois päältä? Ymmärsin, että EXT-filesysteemejä ei enää kehitetä ja Btrfs olisi parempi ja jopa turvallisempi käyttää (osaa pitää tietojärjestelmästä/tiedostoista parempaa huolta?)?

2) Pystyykö tuon erillisen /homen tekemään heti linuxin asennusvaiheessa kun partitiot tehdään vai pitääkö se tehdä asennuksen jälkeen? Onko sillä edes väliä? Onko se "mount point" partitioiden asennusvaiheessa juurikin se toiminto millä tämä tehtäisiin?

3) Ostin/otin juuri käyttöön elämäni ensimmäisen NASsin ja laitoin siihen (yksittäinen levy) Btrfs:n filesysteemiksi, onko tuosta nyt sitten haittaa sen CoW:n osalta kun levyllä on paljon videoita ja musiikkia? Musiikkitiedostot (~300 GB FLAC ja AAC omilta levyiltä) pysyvät täysin muuttumattomina, toki lisää tulee joskus "kirjastoon". Videot myöskin suurelta osin muuttumattomia (~4 TB rippaukset omilta levyiltä) mutta sitten on myös väliaikaiset videot esim. YLE Areenasta ladatut jotka poistan heti katselun jälkeen (ne ovat menneet roskakoriin jonka olen aina tyhjentänyt). En ole vielä kertaakaan nähnyt, että joku tiedosto olisi ilmoitettu muuttuneeksi (joku tuollainen lista niistä on Synologyn DSM-käyttiksen "widgeteissä", aina tyhjänä) vaikka olen testiksi muuttanut joidenkin tiedostojen sisältöä. Olen olettanut, että tuossa on juuri kyse snapshoteista, ehkä olen väärässä. En ole myöskään DSM:n kautta vielä törmännyt, että mistä voisi näitä snapshotteja selata. Onko Btrfs väärä valinta nyt sitten NAS-levyyn?

 

[TenderBeef]

Ja sitten ihan yleisesti; onko mitään yleispäteviä oppaita että mitä kannattaa tehdä heti linuxin (tai juuri Mintin) asennuksen jälkeen esim. tietoturvallisuuden kannalta? Varmaan on defaulttina aika turvallinen mutta itse haluaisin tietää ja varmistaa kaikki ((pakonomainen)tarve hallita/ymmärtää laitetta/softaa on erittäin kova), esim. säätää palomuurin säännöt itse käsin.

Ja jotain hyviä/suositeltavia oppaita linuxin ymmärtämiseen, lähtien ihan perusteista, esim. tiedostojärjestelmästä (siis että mitä kaikki ne lukemattomat kansiot linuxin järjestelmässä ovat/tekevät)? Mielellään englanniksi, suomi on niin kehnoa tietotekniikan sanastossa.

Hankalalta tuntuu heittäytyä täysin uuteen käyttikseen kun vuosikymmenet on opiskellut ja hallinnut Windowsia. Win10:n laitan dual boottiin jotain pelejä varten (ihan ilman mitään isoja säätöjä, siinähän sitten vakoilee microsoftille mitä peliä joskus harvoin pelaan), ja linuksin puolelle Virtualboxiin Win8.1:n nykyisellä koneen lisenssillä sellaisia ohjelmia varten joita ei vaan pysty korvaamaan millään, ja jos ei saa toimimaan WINEssä (onko muita?).

 

[Pertti Kosunen]

Copy on write on pääasiassa hyvä juttu ja sitä ei kannata ottaa pois ellei ole jotain erityistä syytä, se on turvallisempi mm. sähkökatkojen siedossa. Btrfs hyvä puoli isoilla volumeilla on mm. tiedostojärjestelmän tarkistusnopeus ongelman jälkeen (bootissa), ext4 kanssa se voi kestää tuntitolkulla, btrfs kanssa tuo menee hetkessä läpi.

 

[TenderBeef]

Copy on write on pääasiassa hyvä juttu ja sitä ei kannata ottaa pois ellei ole jotain erityistä syytä

Ja @rikn00 mainitsema isot videotiedostot olisivat sellainen syy? Tai mikä olisi sellainen syy?

se on turvallisempi mm. sähkökatkojen siedossa

Tästä sivuten olenkin kysellyt, että miten tuollainen NAS-levy (Btrfs) ja NASsissa kiinni oleva USB-levy (NTFS) selviytyy ilman UPS:ia jos tulee sähkökatko? Asuinseudullani sellaisia ei taida tulla edes yhtä kymmenessä vuodessa mutta silti.. yksi riittää jos se hajottaa molemmat levyt. Toki osa tiedoista, lähinnä muuttumattomat (video/musiikki/etc.) arkistot, erillisillä USB-levyillä ei virroissa.

Hankalia nämä varmuuskopiointihommat kun ei voi mihinkään luottaa yhtään.. ja itsellä kun perfektionismi vähän vaivaa niin siinäpä ne viimeiset hiukset päästä tippuu kun näitä miettii/suunnittelee.

 

[greenlight]

Eihän se tiedostojärjestelmä mihinkään hajoa sähkökatkoksen tullessa. Korkeintaan tuoreeltaan käsitellyt tiedostot voivat hävitä tai korruptoitua. Laitteet voivat mennä fyysisesti rikki vaikka mikä olisi ja varminta olisi aina olla yksi offline-backup.

 

[TheMeII]

Hankalia nämä varmuuskopiointihommat kun ei voi mihinkään luottaa yhtään.. ja itsellä kun perfektionismi vähän vaivaa niin siinäpä ne viimeiset hiukset pääst

Kolme kopiota datalle oma raidi; optinen, nauha tai pilvi ja joku fyysinen toisessa osoitteessa.

 

[TenderBeef]

ja joku fyysinen toisessa osoitteessa

Tämä olisi se paras viimeinen backup-lokaatio, mutta erittäin vaikea käytännössä, ainakin vähänkään muuttuvalle tiedolle.

 

[rikn00]

Kiitoksia vastauksesta! Selvisi jotain mutta myös lisäsi kysymyksiä.

1) Onko tuo snapshot Btrfs:ssä oletuksena käytössä?

1b) Tarkoititko, että sitten /home käyttäisi jotain muuta kuin Btrfs:ää? Esim. EXT4? Vai saako Btrfs:ssä sen CoW:in pois päältä? Ymmärsin, että EXT-filesysteemejä ei enää kehitetä ja Btrfs olisi parempi ja jopa turvallisempi käyttää (osaa pitää tietojärjestelmästä/tiedostoista parempaa huolta?)?

2) Pystyykö tuon erillisen /homen tekemään heti linuxin asennusvaiheessa kun partitiot tehdään vai pitääkö se tehdä asennuksen jälkeen? Onko sillä edes väliä? Onko se "mount point" partitioiden asennusvaiheessa juurikin se toiminto millä tämä tehtäisiin?

3) Ostin/otin juuri käyttöön elämäni ensimmäisen NASsin ja laitoin siihen (yksittäinen levy) Btrfs:n filesysteemiksi, onko tuosta nyt sitten haittaa sen CoW:n osalta kun levyllä on paljon videoita ja musiikkia? Musiikkitiedostot (~300 GB FLAC ja AAC omilta levyiltä) pysyvät täysin muuttumattomina, toki lisää tulee joskus "kirjastoon". Videot myöskin suurelta osin muuttumattomia (~4 TB rippaukset omilta levyiltä) mutta sitten on myös väliaikaiset videot esim. YLE Areenasta ladatut jotka poistan heti katselun jälkeen (ne ovat menneet roskakoriin jonka olen aina tyhjentänyt). En ole vielä kertaakaan nähnyt, että joku tiedosto olisi ilmoitettu muuttuneeksi (joku tuollainen lista niistä on Synologyn DSM-käyttiksen "widgeteissä", aina tyhjänä) vaikka olen testiksi muuttanut joidenkin tiedostojen sisältöä. Olen olettanut, että tuossa on juuri kyse snapshoteista, ehkä olen väärässä. En ole myöskään DSM:n kautta vielä törmännyt, että mistä voisi näitä snapshotteja selata. Onko Btrfs väärä valinta nyt sitten NAS-levyyn?

1) Oletus taitaa riippua distrosta, en osaa valitettavasti sanoa. Googlella varmaan löytyy joku btrfs-opas snapshotteihin.

1b) Joo openSusessa oletuksena /homessa on XFS. Suurin osa distroista käyttää sekä juureen että /homeen oletuksena ext4:sta. ext4 on yleisin käytössä oleva tiedostojärjestelmä ja se toimii oikein hyvin. btfs:n hyödyt ovatkin sen uudet ominaisuudet, mutta huono puoli vielä on mahdolliset ongelmat ja puuttuva tuki joillekin konfiguraatioille (muistaakseni jotkut raid-systeemit eivät taida toimia). XFS sopii ominaisuuksiltaa ymmärtääkseni hyvin datalle, mutta en ole tähän asiaan perehtynyt,

2) Helpoin tapa on heti asennusvaiheessa. Osiointivaiheessa voi olla suoraan vaihtoehto tehdä erillinen /home tai sitten manuaalisen osioinnin kautta. Esimerkiksi voit tehdä osion tyypillä ext4 ja laittaa mount pointiksi "/". Tämä on juurihakemisto eli kaikki mille ei ole muuta osiota määritelty. Teet lisäksi toisen osion, vaikka ext4 tai mikä vaan, ja merkitset mount pointiksi /home. Tämä on sitten kotiosio. Myöhemminkin voi tehdä, mutta sitten pitää osata siirtää tiedostot ja muokata itse mount pointit oikein asetustiedostoihin.

3) Itselle ei ekana tulisi mieleen laittaa btrfs:ää NASsiin, mutta eiköhän sekin kotikäytössä hyvin toimisi. Snapshottaamisen kanssa nuo areenavideot voisivat varata tosiaan tallennustilaa.

 

[Pertti Kosunen]

Ja @rikn00 mainitsema isot videotiedostot olisivat sellainen syy? Tai mikä olisi sellainen syy?

Mm. video-editointiin tai serveri-puolella tietokantojen kanssa tuo voi olla huono, pelkkä isojen tiedostojen säilytys ei pitäisi haitata. Noissa tapauksissakaan en laittaisi btrfs:ä copy on write poistettuna vaan kokonaan eri tiedostojärjestelmän, kun tuo copy on write on olennainen osa ZFS ja btrfs tiedostojärjelmiä.

 

[TenderBeef]

Snapshottaamisen kanssa nuo areenavideot voisivat varata tosiaan tallennustilaa.

Noita videoita olen aina mediasoittimelta katselun jälkeen poistanut, ja sitten myöhemmin tietokoneelta SMB-jaolta tyhjentänyt roskakorista ne pois. Aina on vapaa tila levyllä kasvanut normaalisti poistamisen jälkeen. En kyllä ymmärrä vieläkään mitään snapshoteista että miten ne toimii.. paljon muutakin opiskeltavaa vielä.. tuntuu liian paljolta jopa.

Mm. video-editointiin tai serveri-puolella tietokantojen kanssa tuo voi olla huono, pelkkä isojen tiedostojen säilytys ei pitäisi haitata.

Synologyn DSM:ssä:

 

[jurristi]

Miksiköhän kirkkaankeltainen väri näkyy ruskeana (alla olevassa taulukossa tarkoitettu normaali "keltainen") Ubuntun virtuaaliterminaaleissa, kun käytän mutt-sähköpostiohjelmaa? Värit näkyvät samoilla asetuksilla oikein, kun ohjelman käynnistää pääteikkunassa työpöytäympäristössä.

Päätteen väriasetukset näyttäisivät olevan oikein, eikä niitä muuttamalla pysty vaikuttamaan kyseiseen väriin.

/etc/vtrgb:

1,222,57,255,0,118,44,204,128,255,0,255,0,255,0,255
1,56,181,199,111,38,181,204,128,0,255,255,0,0,255,255
1,43,74,6,184,113,233,204,128,0,0,0,255,255,255,255

Edit. Framebuffer-ajurin (vga16fb) lataaminen auttoi. Olisi silti mukava löytää toinenkin tapa korjata ongelma.

Edit2:

         +--------+--------+---------+
         | Normal | Bright | Color   |
         +--------+--------+---------+
         |      0 |      8 | Black   |
         |      1 |      9 | Red     |
         |      2 |     10 | Green   |
         |      3 |     11 | Yellow  |
         |      4 |     12 | Blue    |
         |      5 |     13 | Magenta |
         |      6 |     14 | Cyan    |
         |      7 |     15 | White   |
         +---------------------------+

Virtuaalipäätteet eivät siis näytä ylipäätään noita kirkkaita värejä (8-15) vaan ainoastaan normaalit värit (0-7), ellei lataa framebuffer-ajuria.

Edit3: Tuon mukaan ilmeisesti vaatii framebufferin käyttöä: Linux pages/cko

Edit4: Ongelma ratkesi, kun muutin komennolla "dpkg-reconfigure console-setup" tuettavan merkistön asetusta ("Guess" -> "Latin 1 ja 5").

 

[TenderBeef]

Opiskelen juuri linuxin tiedostojärjestelmää ja onko tosiaan niin, että ohjelmien asetuksetkin tallentuvat /home hakemistoon ("salattuina" piste hakemiston/tiedoston edessä)? Sitä tässä yritän opiskella, että mistä kaikkialta pitäisi tehdä backuppeja linuxissa? Windowsissahan kun pitää ohjelmien asetustiedostoja/jne. etsiä muutamista eri paikosta talteen.

Jatkokysymys: Jos /home on eri partitiolla ja/tai varmuuskopioitu ulkoiselle levylle ja linux uudellenasennetaan, osaako se uusi järjestelmä automaattisesti, hmm mikähän olisi oikea termi, "ottaa käyttöön" aikaisemmat asetukset sieltä edellisestä /home:sta?

 

[Barbarossa]

Opiskelen juuri linuxin tiedostojärjestelmää ja onko tosiaan niin, että ohjelmien asetuksetkin tallentuvat /home hakemistoon ("salattuina" piste hakemiston/tiedoston edessä)? Sitä tässä yritän opiskella, että mistä kaikkialta pitäisi tehdä backuppeja linuxissa? Windowsissahan kun pitää ohjelmien asetustiedostoja/jne. etsiä muutamista eri paikosta talteen.

Jatkokysymys: Jos /home on eri partitiolla ja/tai varmuuskopioitu ulkoiselle levylle ja linux uudellenasennetaan, osaako se uusi järjestelmä automaattisesti, hmm mikähän olisi oikea termi, "ottaa käyttöön" aikaisemmat asetukset sieltä edellisestä /home:sta?

Periaattessa kaikkiin näihin voi vastata lyhyesti "kyllä".

Hieman tarkennettuna:
Toisin kuin eräissä käyttöjärjestelmän kaltaisissa ympäristöissä, *nix järjestelmissä normaalisti ajetaan ohjelmat käyttäjänä, ja yleensä käyttäjällä ei ole kirjoitusoikeuksia muualle kuin omaan kotihakemistoonsa (eli yksinkertaisimmillaan tuo /home/<käyttäjänimi>), joten käyttäjän asetukset ym. nippelit talletetaan tänne erinäisiin tiedostoihin ja hakemistoihin, mukaanlukien nuo pisteellä alkavat (eli "piilotetut").

Eli varmuuskopioimalla oman käyttäjän hakemiston varmuuskopioit samalla kaikki käyttäjän ohjelmien asetukset, talletukset yms., ja palauttamalla ne samanlaiseen (tai riittävän samankaltaiseen asennukseen) luetaan ne sieltä niinkuin normaalistikin.

Toki poikkeuksia aina löytyy, mutta näissä yleensä syynä on joko käyttäjän omat sössimiset varmuuskopiota tehdessä tai palauttaessa, tai yksinkertaisesti kädetön softa.

Kannattaa huomioida että varsinaisia järjestelmän asetuksia ym. tiedostoja ei pidetä /home:ssa eikä siis koskaan etsitäkään, joten järjestelmän asetuksia et voi varmuuskopioida tätä kautta.

 

[Elvis Jagger]

Ja sitten ihan yleisesti; onko mitään yleispäteviä oppaita että mitä kannattaa tehdä heti linuxin (tai juuri Mintin) asennuksen jälkeen esim. tietoturvallisuuden kannalta? Varmaan on defaulttina aika turvallinen mutta itse haluaisin tietää ja varmistaa kaikki ((pakonomainen)tarve hallita/ymmärtää laitetta/softaa on erittäin kova), esim. säätää palomuurin säännöt itse käsin.

Täällä on paljon ohjeita, lähinnä Ubuntu/Mint ja aika aloittajaystävälliseen tyyliin:

Easy Linux tips project

Ja jotain hyviä/suositeltavia oppaita linuxin ymmärtämiseen, lähtien ihan perusteista, esim. tiedostojärjestelmästä (siis että mitä kaikki ne lukemattomat kansiot linuxin järjestelmässä ovat/tekevät)? Mielellään englanniksi, suomi on niin kehnoa tietotekniikan sanastossa.

https://www.thegeekstuff.com/2010/09/linux-file-system-structure/

Käytännössä sun ei tarvitse tietää noista kuin ehkä /home, /media, /opt jos joskus asennat itse ohjelmia muualta kuin repoista ja /usr/bin jos pitää etsiä manuaalisesti missä joku suoritettava ohjelma on.

Ohjelmien asetustiedostot on /home/<user> tai siellä /.config kansiossa. Siinä ei taida olla mitään logiikkaa, että kummassa ne on ja jotkut pienemmät ohjelma tekee vain yhden .tiedoston (ei kansion) /homeen. Mutta ovathan ainakin kaikki yhden kansion takana, eikä niin kuin Windowsissa jossa niitä niiden paikkaa saa aina arpoa.

 

[jurristi]

Noista TenderBeefin kysymyksistä vielä:

Järjestelmänlaajuiset asetustiedostot ovat hakemistossa /etc ja sen alihakemistoissa.

En ole varma, mitä jälkimmäisellä kysymyksellä tarkoitettiin, mutta jos käyttöjärjestelmä asennetaan uudelleen ja kotihakemiston sisältävän osion liitospisteeksi määritetään asennuksen yhteydessä tai myöhemmin /home, osiolla oleva vanha kotihakemisto toimii uutena kotihakemistona ja ohjelmat löytävät siellä olevat asetukset normaalisti edellyttäen, että käyttäjänimi on edelleen sama tai hakemiston nimi on muutettu vastaamaan uutta käyttäjänimeä.

 

[apoiuyt]

Ymmärtääkseni käyttäjäkohtaiset asetukset on /home -hakemistossa, globaalit sitten jossain muualla.

Itse oon vaan yleensä ottanut kotikansion talteen mutta se on sellainen laiskan miehen temppu kun en ole jaksanut opiskella sen kummemmin linuxin saloja. Niin harvoin kuitenkin tulee käyttökonetta asenneltua ettei tuolla ole ollut mulle väliä ja mun use case on muutenkin niin peruskamaa että ei ole kovin paljoa asetettavia parametreja.

Edit. Hidaaaaasssss

 

[TenderBeef]

Kannattaa huomioida että varsinaisia järjestelmän asetuksia ym. tiedostoja ei pidetä /home:ssa eikä siis koskaan etsitäkään, joten järjestelmän asetuksia et voi varmuuskopioida tätä kautta.

Järjestelmänlaajuiset asetustiedostot ovat hakemistossa /etc ja sen alihakemistoissa.

Kiitoksia kaikille vastauksista. Vielä tästä jos kysyn, että onko mitään helppoa tapaa (joku erillinen softa, tai sitten komento terminaalista, tai joku tietty hakemisto järjestelmästä (tuo mainittu /etc kokonaan?)) ottaa "kaikista" järjestelmän asetuksista varmuuskopiot? Ei ehkä ole niin tarpeen, mutta jos helposti onnistuisi niin miksei. Tarkoitus olisi yrittää päästä mahdollisimman vähällä säätämisellä (ja sitä kautta opiskelemisella) mutta kuitenkin handlata perusasiat, varmuuskopioinnit ja etenkin tietoturvallisuus.

 

[rikn00]

Kiitoksia kaikille vastauksista. Vielä tästä jos kysyn, että onko mitään helppoa tapaa (joku erillinen softa, tai sitten komento terminaalista, tai joku tietty hakemisto järjestelmästä (tuo mainittu /etc kokonaan?)) ottaa "kaikista" järjestelmän asetuksista varmuuskopiot? Ei ehkä ole niin tarpeen, mutta jos helposti onnistuisi niin miksei. Tarkoitus olisi yrittää päästä mahdollisimman vähällä säätämisellä (ja sitä kautta opiskelemisella) mutta kuitenkin handlata perusasiat, varmuuskopioinnit ja etenkin tietoturvallisuus.

/etc suora kopioiminen talteen ihan hyvä ratkaisu. Jotkin poikkeusasetukset saattavat sijaita muuallakin (esim. bootleaderista riippuen jotain voi olla /boot:n alla), mutta ne taitavat olla aika vähissä. /etc:tä ei kyllä kannata suoraan kopioida uuteen järjestelmään, koska esimerkiksi mountpoint-asetuksissa voi olla viilattavaa, koska osiot ja niiden nimeäminen voivat vaihdella. Yleensä jos muokkaa itse jotain asetusta, niin tietää sen sitten tarvittaessa ottaa talteen.

 

[jurristi]

Kiitoksia kaikille vastauksista. Vielä tästä jos kysyn, että onko mitään helppoa tapaa (joku erillinen softa, tai sitten komento terminaalista, tai joku tietty hakemisto järjestelmästä (tuo mainittu /etc kokonaan?)) ottaa "kaikista" järjestelmän asetuksista varmuuskopiot? Ei ehkä ole niin tarpeen, mutta jos helposti onnistuisi niin miksei. Tarkoitus olisi yrittää päästä mahdollisimman vähällä säätämisellä (ja sitä kautta opiskelemisella) mutta kuitenkin handlata perusasiat, varmuuskopioinnit ja etenkin tietoturvallisuus.

Eikös tuossa Mintissä ole valmiiksi asennettuna varmuuskopiointisovellus (Backup Tool ?) graafisella käyttöliittymällä?

Komentorivisovelluksista rsync lienee eniten käytetty tuohon tarkoitukseen.
1) rsync - ArchWiki
2) rsync – Linux.fi

 

[Elvis Jagger]

Eikös tuossa Mintissä ole valmiiksi asennettuna varmuuskopiointisovellus (Backup Tool ?) graafisella käyttöliittymällä?

Tuo ei taida edelleenkään osata tehdä muuta kuin pakata /homen ja ottaa asennetuista paketeista listan, mikä hoituu erilliselläkin komennolla.

 

[jurristi]

Selvä. Ei ole mitään kokemusta Mintistä.

 

[TenderBeef]

https://www.thegeekstuff.com/2010/09/linux-file-system-structure/

Tässä linkki tiedostojärjestelmän standardi-spekseihin jos kiinnostaa syvempi asian tutkiminen, uusin versio 3.0 on julkaistu 2015 kesällä, sitä edellinen versio 2.3 on vuodelta 2004.

 

[FireExit]

Löytyskö täältä GRUB2 guruja kun tuli mielenkiintoinen ajatus päähän:

Eli jos on asentanu esim. Samsung 960 EVO NVMe M.2 SSD-levyn adapterilla (esim. tälläinen Silverstone M.2 PCIe x4 laajennuskortti - 27,00€) PCIe-väylään emolevyssä josta ei itsestään löydy PCIe M.2 NVMe-paikkaa, niin voiko sinne asennetun käyttiksen bootata niin et asentaa sen 960:n rinnalle toisen levyn, joka on SATA-väylässä kiinni, ja asentaa sinne GRUB2:n joka on konfattu osoittamaan tuonne 960:n asennettuun käyttikseen?

Eli tuollaisessa emossa jossa ei löydy PCIe M.2 NVMe -paikkaa ei löydy suoraan tukea boottaukselle sinne asennetulle käyttikselle joka on se ongelma jonka haluan ratkaista.

Niin eikö se ratkea tuolla järjestelyllä: BIOS/UEFI:ssä boottilevyksi SATA-väylässä oleva kovo, jossa sijaitsee GRUB2 joka vetää M.2 NVMe -levyltä käyttiksen käyntiin?

 

[jokujossai]

Löytyskö täältä GRUB2 guruja kun tuli mielenkiintoinen ajatus päähän:

Eli jos on asentanu esim. Samsung 960 EVO NVMe M.2 SSD-levyn adapterilla (esim. tälläinen Silverstone M.2 PCIe x4 laajennuskortti - 27,00€) PCIe-väylään emolevyssä josta ei itsestään löydy PCIe M.2 NVMe-paikkaa, niin voiko sinne asennetun käyttiksen bootata niin et asentaa sen 960:n rinnalle toisen levyn, joka on SATA-väylässä kiinni, ja asentaa sinne GRUB2:n joka on konfattu osoittamaan tuonne 960:n asennettuun käyttikseen?

Eli tuollaisessa emossa jossa ei löydy PCIe M.2 NVMe -paikkaa ei löydy suoraan tukea boottaukselle sinne asennetulle käyttikselle joka on se ongelma jonka haluan ratkaista.

Niin eikö se ratkea tuolla järjestelyllä: BIOS/UEFI:ssä boottilevyksi SATA-väylässä oleva kovo, jossa sijaitsee GRUB2 joka vetää M.2 NVMe -levyltä käyttiksen käyntiin?

Itselläni erillinen /boot-osio SATA-levyllä ja Ubuntu asennettuna PCI-E levyllä. Asennuksen yhteydessä luodaan osioinnissa erillinen /boot-osio ja grub asennetaan SATA-levyn pääkäynnistyslohkoon. UEFI-asennuksessa pitää efi-osio olla myös SATA-levyllä, että pystyy boottaamaan.

 

[FireExit]

Itselläni erillinen /boot-osio SATA-levyllä ja Ubuntu asennettuna PCI-E levyllä. Asennuksen yhteydessä luodaan osioinnissa erillinen /boot-osio ja grub asennetaan SATA-levyn pääkäynnistyslohkoon. UEFI-asennuksessa pitää efi-osio olla myös SATA-levyllä, että pystyy boottaamaan.

Sainki jo vastauksen toisessa ketjussa samaan kyssäriin ja sielä KognaK vinkkasi myös tällästä ratkaisua: [Guide] NVMe-boot without modding your UEFI/BIOS (Clover-EFI bootloader method)

 

[8540]

@FireExit , itse tein tuon GRUB:ssa Arch wikin mukaan, eli:
Muuten perus asennus, mutta boot osion tosiaan alustat tuolle SATA-levylle. Sitten osioit PCI-E -levyn varsinaiselle käyttöjärjestelmälle, ja mounttaat tämän SATA-osion /boot kohtaan (mount /dev/sdXy /mnt/boot (/mnt koska tässä asennusvaiheessa vielä ei olla chrootattu asennettavaan järjestelmään, aikaisemmin asennuksessa siis ollaan tässä tapauksessa PCI-E tallennusmedia mountattu /mnt kohtaan)). Sitten perus asennus järjestelmälle ja GRUB:ia asennettaessa EFI-bootatessa ohjataan tuonne /boot osioon, ja BIOS-bootattaessa kiintolevylle:
EFI:
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub
(Huom: Jotkut järjestelmät lienee vaativat että --efi-directory=/boot/efi)
BIOS:
grub-install /dev/sdX
(Oletus target on i386-pc, viilaa halun mukaan)

Muistin mukaan muuta erikoista tähän liittyen ei ollut.
Ja sitten tosiaan BIOS:n ohjaat boottamaan tuon SATA-levyn, ja siellä sijaitseva bootloaderi sitten käynnistää järjestelmän PCI-E -levyltä.
Kannattaa katsella Arch wikistä lisätietoja;
GRUB - ArchWiki
GRUB/Tips and tricks - ArchWiki

En tiedä kuinka sinun järjestelmässäsi tuo hoituu, mutta ainakin Arch:ssa, kun asennus tapahtuu komentolinjalta, menee asennus yllämainitulla tavalla.
Bootloaderihan voi olla tosiaan vaikka USB-tikulla jos niin haluaa.

Sinänsähän tuo SATA menee vähän hukkaan kun ei sieltä tarvitse bootloaderille kuin 300-500 MB. Loputhan voi sitten osioida toki vaikka lisävarastoksi.

 

[TenderBeef]

Vielä partitioinnista, tarkoitus olisi käyttää Virtualboxissa Win8.1:stä ja jos laitan /home:n omalle Btrfs-partitiolle, niin onko hölmöä pitää virtuaalilevytiedostoa tuolla partitiolla? Pitäisikö tehdä sille ihan oma partitio esim. EXT4, tai joku muu parempi FS? Haluaisin kuitenkin käyttää Btrfs:ää /home:ssa sen ominaisuuksien takia, esim. käsittääseni se osaa tarkistella bit-rot:ia automaattisesti.

Ja swapista vielä kysäisisin, aika laidasta laitaan on ohjetta, että minkä kokoiseksi partitiota kannattaisi laittaa. Olen ymmärtänyt, että kun tarkoitus on käyttää hibernatea, niin swappi täytyy olla vähintään RAM-määrä. Yleisesti suositukset menee x-RAMx2 haarukkaan; mitä etua kaksinkertaisesta RAM-määrän swapista on? Meneekö se niin, että hibernatetiedosto käyttää RAMmin verran tilaa + swap RAMmin verran tilaa (tai ehkäpä pitäisi sanoa, että "varataan" mahdollisen tilanteen varalle), eli yhteensä 2x RAM?

 

[=JP=]

Meinasin ehdottaa swap file käyttöä, mutta btrfs ei näköjään tue tuota vielä. Btrfs tuntuu olevan asia josta ollaan montaa mieltä, Red Hat jopa pudotti sen tuen kokonaan tovi sitten. Kannattaa pitää backupit kunnossa!

FAQ - btrfs Wiki
Is btrfs stable?
Short answer: Maybe.

 

[greenlight]

Btrfs on ihan normaali tiedostojärjestelmä, turha sen kanssa on vatvoa, että kannattaako sitä käyttää tämän- tai tuonlaisten tiedostojen säilyttämiseen. Jos tietää, että jokin käyttötapaus on btrfs:n erityisominaisuudet huomioiden heikko, niin esimerkiksi copy-on-writen voi disabloida käyttämällä komentoa chattr +C.

Itse en näe siitäkään mitään hyötyä, että /home olisi kokonaan erillisellä osiolla, kun brtfs:ssä on tämä subvolumeiden konsepti olemassa. Eikä kannata sekoittaa tiedostojärjestelmien ja osioiden käsitteitä keskenään.

 

[Pertti Kosunen]

Btrfs tuntuu olevan asia josta ollaan montaa mieltä, Red Hat jopa pudotti sen tuen kokonaan tovi sitten.

Tuo päätös ei ollut tietääkseni tekninen vaan poliittinen, Red Hatilla on joku oma systeemi tulossa jota haluavat puskea väkisin eteenpäin.

 

[Xiyng]

Vielä partitioinnista, tarkoitus olisi käyttää Virtualboxissa Win8.1:stä ja jos laitan /home:n omalle Btrfs-partitiolle, niin onko hölmöä pitää virtuaalilevytiedostoa tuolla partitiolla? Pitäisikö tehdä sille ihan oma partitio esim. EXT4, tai joku muu parempi FS? Haluaisin kuitenkin käyttää Btrfs:ää /home:ssa sen ominaisuuksien takia, esim. käsittääseni se osaa tarkistella bit-rot:ia automaattisesti.

Kun en Btrfs:stä mitään tiennyt aiemmin, aloin selvitellä, mistä on kyse, ja löysin vuodelta 2016 tällaisen artikkelin. Erityisesti tämä pätkä Final notes -otsikon alta saattaa kiinnostaa sinua: "As in any technology, BTRFS is not perfect. For example, it suffers when there are heavy write activities in the middle of an existing files, so probably it’s not the best candidate for virtualization (the virtual disks are updated in-place at each write)." Tilanne on toki voinut sittemmin muuttua.

 

[8540]

Tuo virtualboxin käyttö on kerrottu olevan huonohko? yhdistelmä CoW-ominaisuuden kanssa. Ei sille omaa partitiota kannata alkaa tekemään, mutta yleisesti on suositeltavaa ottaa tuo CoW-ominaisuus pois käytöstä. CoW:n voi kytkeä pois päältä kansiolle jota virtualbox käyttää sen imagen säilömiseen, joka on yleensä ~/Virtualbox VMs. Tämä pitää tehdä ennenkuin sitä dataa sinne tallentaa, sillä CoW:n disablointi on käytössä vain uusille tiedostoille.
Btrfs - ArchWiki
En oikein itse ymmärrä syytä miksi CoW+Virtualbox on huono yhdistelmä, mutta useammassa lähteessä tätä yhdistelmää ei suositella. Jotain tietoa löysin viitaten ettei virtualbox välttämättä toimi oikein tai ollenkaan CoW-ominaisuuden kanssa, liekkö sitten johtuu siitä että virtualboxin "levy" on oikeasti yksi iso tiedosto.

Jos bit rotin ehkäisyllä tarkoitat esim. scrubia niin se pitää ottaa erikseen käyttöön, ei ole defaulttina. Lisäksi en tiedä kuinka suuri hyöty scrub:sta on ilman raidia. Näköjään myös defragmentointi pitää erikseen ottaa käyttöön mount optiolla. En tiedä kuinka herkkä btrfs on fragmentoitumaan tosin.

CoW:n disablointi on varmasti pienemmän vaivan tie kuin lähteä osioimaan.

En ole ikinä kuullut että swap kannattaisi olla yli RAM:n. Käsittääkseni tämä olisi jokin vanha ohje vanhoista servereistä joissa ei ollut juuri muistia, mutta tuplaten RAM on nykypäivänä varsin iso osa levytilaa.
Swap pitää olla niin iso kuin sinne haluat dataa mahtuvan, valmiustilaa käytettäessä vähintään sen verran kuin RAM:ssa on tavaraa silloin kuin valmiustilaan mennään. Jos muisti on lähes täynnä valmiustilaan mennessä, niin silloin on oltava RAM:n kokoinen swap. Jos RAM on oikeasti täynnä ja täten swap-tilaa joudutaan käyttämään ja sitten mennään valmiustilaan, vaadittaneen silloin swap-tilan senhetkisen käytön verran + RAM:n verran että voidaan luotettavasti mennä valmiustilaan, joskin käsittääkseni kernel kykenee tekemään tilansäästöihmeitä ja määrittelemään tarkemmin esim. swapatun tiedon tarpeellisuutta. Tämä on kuitenkin sellainen tilanne, mikä nykykoneilla harvoin ilmenee ja muutoinkin koneen pitäminen niin suurella "yli"käytöllä ei ole nopeaa eikä omasta mielestäni järkevää.

Swapin lopullinen koko on riippuvainen käyttökohteesta, saatavilla olevasta kovalevytilasta ja erityisesti RAM:n määrästä. Swapilla kun on kaksi tehtävää, se toimii muistin jatkeena jos muisti loppuu kesken (hidastaa toki konetta johtuen levyjen hitaammasta toiminnasta), sekä on luontevin keino mahdollistaa valmiustilan käyttö.

Sanoisin että jos sinulla on alle 8 GB RAM:ia ja kovalevytila ei ole ongelma, voi swapin koko olla sen RAM:n verran normaalikäytössä, jossain alle 2-4 GB:n RAM:lla voisi ylikuormitetussa käytössä olla asiallista käyttää 1,5-2x RAM:n määrää swaptilana johtuen liian pienestä RAM:sta suhteessa nykypäivän prosesseihin. Itse en kuitenkaan ole nähnyt tarvetta missään tilanteessa yli 8 gigaiselle swapille, vaikka muistia onkin käytössä 16-32 gigaa eri koneissa, sillä itsellä muistin verraten suuri määrä johtaa siihen että swappia ei tarvita kuin valmiustilaa varten (eli RAM ei lopu yleensä kesken, ja tähän olen myös tähdännyt muistia ostaessani), enkä konetta valmiustilaan pistä tilanteesta jossa koneella on niin valtava kuormitus että RAM:ia on käytössä yli 6-8 gigaa. Valmiustilasta herääminenkään ei ole tuossa vaiheessa enää mitenkään vilkasta.
Helppokäyttöisissä distroissa kuten Mint on swapin tila yhtäkuin RAM:n määrä. Jos et ole varma, on tämä se varmin tie.

Myös swappausherkkyyttä voi sitten säätää "swappiness" arvolla. Nykyisen arvon saa esiin komennolla:
cat /sys/fs/cgroup/memory/memory.swappiness
Oletuksena tämä on 60. 0 tarkoittaa että swap ei ole käytössä, 1 tarkoittaa että swappia käytetään vain jos RAM on täysin loppu, 100 tarkoittaa että kaikki swapataan lähes välittömästi. Olen kuullut että tämä luku tarkoittaisi vapaana olevan muistin määrää prosentteina kun swappia aletaan käyttämään, mutten ole tästä aivan varma. Oli totta tai ei, kutakuinkin niitä linjoja se näyttää menevän.
Swappiness-arvoa voi säätää tiedoston sysctl.conf kautta, johon lisätään laini "vm.swappiness=xx", missä xx siis kuvastaa haluttua swappiness-arvoa. Omassa käytössä hyväksi olen havainnut luvun 10, mikä on yleisesti suositeltu arvo jos RAM:ia on tarpeeksi. Tällöin swappia käytetään kun RAM alkaa olla liki täynnä, muttei ole vielä totaalisesti loppu. Oman muistimäärän johdosta en ole aina käyttänyt koko swappia lainkaan, ja nykyään käytössä on swaptiedosto osion sijaan sen joustavuuden vuoksi.

 

[greenlight]

Tuo päätös ei ollut tietääkseni tekninen vaan poliittinen, Red Hatilla on joku oma systeemi tulossa jota haluavat puskea väkisin eteenpäin.

Päätös taisi kuitenkin perustua teknisiin haasteisiin integroida btrfs:n muutokset heidän omiin julkaisuihinsa. Koska se ei ollut heidän standardeillaan riittävän valmis seuraavan suuren RHEL 8 -julkaisun lähestyessä, niin teknologiademona nähty ominaisuus pudotettiin pois.

 

[TenderBeef]

Kun en Btrfs:stä mitään tiennyt aiemmin, aloin selvitellä, mistä on kyse, ja löysin vuodelta 2016 tällaisen artikkelin.

Oli hyvä artikkeli, pro-Btrfs toki mutta mielestäni hyvin perusteluin, varsinkin puhe muutospelosta oli hyvä. Itsekin jos nyt Windows-maailmassa pitäisi/haluaisi vaihtaa tai joku suosittelisi vaihtamaan NTFS:n johonkin toiseen tuntemattomaan, niin varmasti löytyisi itsestäni myös muutosvastarintaa ja epäilyksiä.

Kommenttiosiosta löysin vielä tällaisen maininnan:

If you wanna try it, use the latest Kernel and not any outdated Debian or Ubuntu LTS.

En ole mikään linux-guru mutta sen verran olen/luulen olevani asioista tietoinen, että jos asennan Linux Mint 18.3:n niin siinähän on varmaan aika vanha kerneli koska tuo distro pohjautuu vähän vanhempaan Ubuntu 16.04 LTS:ään. En ymmärrä vielä kernelin päälle oikeastaan yhtään mitään joten voin olla väärässä, mutta olisiko suositeltavaa sitten päivittää kerneliä asennukseen? (Näinhän tässä niitä säätöjuttuja alkaa kerääntyä vaikka ajatus oli, että mahdollisimman vähän käyttiksen säätämistä)

Jos bit rotin ehkäisyllä tarkoitat esim. scrubia niin se pitää ottaa erikseen käyttöön, ei ole defaulttina. Lisäksi en tiedä kuinka suuri hyöty scrub:sta on ilman raidia.

Tunnustan, ei mitään hajua mistään scrubista mikä se on, eikä mitään tarkkaa tietoa tuosta Btrfs:n bitrot-fiitseristä. Olen ymmärtänyt, että Btrfs ihan ilman RAIDiakin osaisi tunnistaa ja ilmoittaa bit rotista.. korjaus onnistuisi myös sitten RAID-konfiguraatiolla.

Näköjään myös defragmentointi pitää erikseen ottaa käyttöön mount optiolla. En tiedä kuinka herkkä btrfs on fragmentoitumaan tosin.

Koneeseen vaihtuu SSD-levy tuohon linux+win dual boottiin joten eipä kait ole tarpeellinen.

En ole ikinä kuullut että swap kannattaisi olla yli RAM:n.

Kuten kirjoitin, googlettamalla löytyy kyllä paljon erilaisia suosituksia, ja monet toteavat, että mitään eksaktia vastausta ei taida löytyä, eli monet taitaa suositella ihan mutulla.

Sanoisin että jos sinulla on alle 8 GB RAM:ia ja kovalevytila ei ole ongelma, voi swapin koko olla sen RAM:n verran normaalikäytössä

8 GB löytyy. Alunperin ajattelin googlauksen jälkeen, ennen kun lähdin täällä kyselemään, että laitan kompromissina 10 GB osion, ehkä laitan sen kuitenkin, ei ole gigatavun päälle tarkkaa itsellä, ja kaippa noita osioita voi Gpartedilla jälkeenpäin sohia kohtuullisen turvallisesti. BTW, kirjoitat vastauksessasi koko ajan "valmiustilasta" ja, että RAM-muisti dumpattaisiin swappiin silloin. Piti ihan googlettaa kun menin sekaisin, eikä suomenkieliset tietotekniset termit ole tuttuja (enkä pidä niistä kun ne on monesti aivan surkeita ja sekoittavia), "valmiustila" näyttäisi olevan sama asia kuin "lepotila", eli "standby", eli silloin ei RAMmia dumpata levylle. Hibernate taitaa olla suomeksi "horrostila", ainakin Microsoftin mielestä.

 

[TenderBeef]

Tuntuu, että uusia kysymyksiä/selviteltävää tulee vaan enemmän ja enemmän mitä enemmän kyselee/tutkii asioita.

Itse en näe siitäkään mitään hyötyä, että /home olisi kokonaan erillisellä osiolla, kun brtfs:ssä on tämä subvolumeiden konsepti olemassa. Eikä kannata sekoittaa tiedostojärjestelmien ja osioiden käsitteitä keskenään.

Lisää opiskeltavaa, katsoin alustavasti täältä mutta eipä nyt vielä kauheasti avautunut tuo ominaisuus. Ilmeisesti kuitenkin tarkoittaa, että subvolume on "tiedosto/kansio" Btrfs-tiedostojärjestelmässä? Menee ehkä minulle liian vaikeaksi.. ainakin tässä vaiheessa. Mutta eikös kuitenkin oma /home partitio olisi selvempi/kätevämpi ainakin siinä tapauksessa jos joutuu linuxin asentamaan uudestaan? Ainakin selvempi olisi tällaiselle noobille.

Tuo virtualboxin käyttö on kerrottu olevan huonohko? yhdistelmä CoW-ominaisuuden kanssa. Ei sille omaa partitiota kannata alkaa tekemään, mutta yleisesti on suositeltavaa ottaa tuo CoW-ominaisuus pois käytöstä. CoW:n voi kytkeä pois päältä kansiolle jota virtualbox käyttää sen imagen säilömiseen, joka on yleensä ~/Virtualbox VMs. Tämä pitää tehdä ennenkuin sitä dataa sinne tallentaa, sillä CoW:n disablointi on käytössä vain uusille tiedostoille.
Btrfs - ArchWiki

"chattr +C" komennosta kirjoitetaan näin:

This will disable copy-on-write for those operation in which there is only one reference to the file. If there is more than one reference (e.g. through cp --reflink=always or because of a filesystem snapshot), copy-on-write still occurs.

Tuo punaisella oleva osio jäi mietityttämään, en vielä tarkkaan ymmärrä snapshottien päälle, edes onko se automaattisesti toiminnassa vai pitääkö säätää käsin. Mutta ilmeisesti snapshottien käyttö voi aiheuttaa ei-halutun tilanteen.

 

[8540]

Toki uusimmassa kernellissä on aina ajantasaisimmat tuet, mutta koska Mint perustuu Ubuntun LTS (Long Term Support) jakeluun ja täten käyttää LTS-kerneliä, ainakin oletuksena, backportataan sinne tärkeiksi määritellyt muutokset, kuten tietoturvaan liittyvät asiat. Mintissäkin kerneliä voi vaihtaa ihan sisäänrakennetun päivitysohjelman kautta.

SSD-levyä käytettäessä kannattaa muistaa ottaa trim käyttöön, sekään ei ole oletuksena. Muistaakseni tämä onnistui lisäämällä mount optioihin (/etc/fstab siis) "discard" optio. Toinen vaihtoehto on käyttää erikseen fstrim:iä, mikä toimii järjestelmän servicenä automaattisesti tietyllä aikaintervallilla.

Muistan etten itse swapista paljoa käsittänyt kun Windowsmaailmasta silmäni muille aukaisin. Itseäni myöskin tuolloin ihmetytti useat erilaiset ohjeet, lähinnä kokeilun kautta se oikea määrä sieltä löytyy, on tosiaan järjestelmästä ja käytöstä riippuvainen ja lienee tästä johtuen myös suosituksia on joka lähtöön. Perussuositus virallisissa ohjeissa on kuitenkin RAM:n verran laittaa, millä paras mennä eteenpäin jos omaa käsitystä tarpeesta ei ole vielä kehittynyt.

En ole käyttänyt btrfs:ää enkä täten itse tiedä kuinka sen koon muuttaminen jälkikäteen onnistuu. AInakin ext4:ssä kannattaa tässä tapauksessa käyttää LVM:ää joka lisää joustoa osioiden rakentumisen ja muuttamisen suhteen. Käsittääkseni btrfs toimii yhteen myös LVM:n kanssa mutta en tosiaan tiedä kuinka helppoa koon muuttaminen ilman sitä btrfs:ssä on.

Itsellekkään ei nuo suomenkieliset termit ole lainkaan tuttuja, enkä viitsinyt lähteä edes etsimään. Mikäli nuin on, tarkoitin hibernatea. Jokatapauksessa se tila kun muisti dumpataan levylle eikä RAM:ia pidetä sähköistettynä. Taisipa olla että nuo ovat vielä tosiaan Microsoftin termejä, ainakin joissain yhteyksissä olen Linux-maailmassa kuullut nuiden sijaan käytettävän termejä "Suspend to RAM" ja "Suspend to disk", jotka mielestäni kertovat paljon kuvaavammin mitä tulee tapahtumaan. Tämä suspend to disk -ominaisuus on se johon edellisessä viestissäni viittasin, oli sopiva suomennos mikä hyvänsä.

Tuosta /homesta sen verran että itse näen sen järkeväksi erillisellä osiolla jos vaihtelee käyttöjärjestelmää (tai kovalevylayoutin kannalta se on muutoin järkevää), sillä tuolla on kaikki normaalikäytössä käyttäjään liittyvä data, eikä tätä dataa täten tarvitse kopioida edestakaisin asennettaessa toista järjestelmää, kun järjestelmä ja /home ovat eri asia ja täten vaihtaessa vaikka distroa ei /homeen tarvitse koskea. En tiedä juurikaan btrfs:stä mutta äkkiseltään kuulostaisi että subvolume on kuitenkin riippuvainen päävoluumista jolla oletettavasti käyttöjärjestelmä olisi, tehden täten /homen siirtämisen uuteen järjestelmään kenties riskialttiiksi varmuuskopioimatta. Käsittääkseni erillinen /home on aika suosittu toimintatapa Linux-maailmassa. Itselläni esim. läppärissä on m.2 SSD:llä itse järjestelmä ja /home on sitten erillisellä vanhanmallin kovalevyllä suuren tilakapasiteetin vuoksi. /home sitten mountataan fstab:ssa erilliseltä kovalevyltä bootin aikana.
/homessa myös pidetään käyttäjäkohtaisia asetuksia, erityisesti eri sovellusten asetuksia, kuten selaimen käyttäjäkohtaiset asetukset ja historiat. Uuteen järjestelmään asennetut samat sovellukset osaavat ottaa ne myös täältä sitten automaattisesti käyttöön, siten vähentäen esim. distron vaihtamisen työtä.

Snapshotit täytyy erikseen luoda, niitä ei luoda automaattisesti. Pöytäkäytössä en näe snapshotille hyötyä, vaan on hyödyllinen esim. NAS:ssa sen tarjoaman muutoshistorian vuoksi, sekä yleisesti snapshottien kautta ainakin ZFS:ssä kannattaa tehdä varmuuskopiointi ("replication task") jos backup-järjestelmä myös käyttää ZFS:ää. Myös vanhat snapshotit täytyy erikseen poistaa, sillä ne vievät tilaa koska ne sisältävät tiedostohistorian ja täten poistamasi tai muuttamasi data siirtyy vain snapshottiin, snapshotin koon vastatessa tehtyjen muutosten kokoa.
Myöskään tuota scrubia en näe hyödyllisenä työpöytäkäytössä. NAS:ssa se itsellä on käytössä, muualla ei. Scrubissa siis kaikki levyn sisältämä data luetaan ja tarkistetaan, sekä mahdollisesti korjataan jos "korrektia" dataa on saatavilla. Täten isommalla datamäärällä tämä vie kohtuu paljon aikaa ja resursseja joka on muusta toiminnasta pois. Esimerkiksi viimeisimmässä oman NAS:n scrubissa se vei 1,3 TB:n tarkistamisessa 6 tuntia ja 20 minuuttia, 2,6 TB:n tarkistamisessa 8 tuntia ja 6 minuuttia sekä 3,7 TB:n tarkistamisessa 17 tuntia ja 5 minuuttia (osa vaihtelusta toki johtuu myös muusta samanaikaisesta rasituksesta, joskin scrubit ovat ajoitettu aikaan jolloin NAS:n käyttö on yleisesti vähäisintä, isommalla datalla tämä toki tuppaa kantamaan päivään saakka jolloin loppuosa scrubista hidastuu muun käytön vuoksi). Toki työpöytäkäytössä datakin on pienempää, mutta on se kuitenkin kohtuu pitkäkestoinen prosessi. ZFS ainakin toimii siten että dataa tallennettaessa luodaan tarkistussumma, joka tarkistetaan aina kun dataa luetaan ja RAID-poolissa virheen löytyessä korrektia dataa haetaan toiselta levyltä. Scrub on ajastettu prosessi joka lukee levyn dataa ja täten aiheuttaa tarkistussumman tarkistamisen kaikelle datalle, ja virheitä huomatessaan hakee toiselta levyltä (jos RAID) korrektin datan ja kirjoittaa sen korruptoituneen tilalle. Ja tosiaan, tästä tulee tuo "bit rotin" ehkäisy. Yhdellä levyllä se voidaan ainoastaan havaita, mutta ei korjata.
Sen kummempia tutkimatta olettaisin että btrfs noudattaa samankaltaista periaatetta, tästä voin toki olla varsin väärässäkin. Btrfs, kuten ZFS, ovat ennemminkin suunniteltu serverikäyttöön, kun ext4 lähinnä työpöydälle.
En aikaisemmin muistanut tarkalleen scrubinkaan toimintaa, piti kerrata......

Helpoin lienee olisi tosiaan kun teet yhden osion bootille, toisen itse käyttöjärjestelmälle ja kolmannen /homelle. Riippuu sitten varmasti distrosta kuinka helppoa tämäkin on, Arch:ssa kun itse joudut keksimään komennot millä mitään saat aikaan ja Mintissä on checkboxit samoille asioille.

 

[Electrolytic]

Tarkoitin tosiaan tallennustilan 100% täyttymistä

Armbianissa ja Dietpissä löytyy tälläisiä valikossa olevia asetuksia siellä terminaalissa. Yleensä ovat sinisellä pohjalla.

Minulla on ensimmäisen malli RasPi Motioneyellä kuvaamassa pihassa vierailevia elukoita (syksyllä kuviin jäi, kun 6 joutsenta marssi jonossa pihan poikki). En edes viitsi RasPilla poistaa vanhoja avi- ja jpg-tiedostoja vaan irrotan muistikortin ja tyhjennän Motioneyen tallennuskansion PC:n muistikortinlukijassa. Tämä säästää aika paljon hermoja, kun vanha RasPi on toiminnoiltaan aika hidas tuohon hommaan.

 

[TenderBeef]

Jotenkin missasin 8540:n postauksen..

SSD-levyä käytettäessä kannattaa muistaa ottaa trim käyttöön, sekään ei ole oletuksena. Muistaakseni tämä onnistui lisäämällä mount optioihin (/etc/fstab siis) "discard" optio. Toinen vaihtoehto on käyttää erikseen fstrim:iä, mikä toimii järjestelmän servicenä automaattisesti tietyllä aikaintervallilla.

Googlasin vähän ja tuon "discardin" käyttöä ei suositella enää. Esim. täällä, jossa myös muitakin (päteviä?) huomioita/vinkkejä: SSD: how to optimize your Solid State Drive for Linux Mint 18.x, Ubuntu 16.04 and Debian - Easy Linux tips project

• Jätä vähän tilaa levylle osioimatta?

• SSD:n Tiedostojärjestelmäksi suositellaan EXT4, Btrfs:tä oli varoitus: "Note: don't select the BTRFS file system! Because under certain circumstances, BTRFS causes a huge amount of write actions." Pitääköhän tämä vieläkin ihan paikkansa?

• "Access time stamp":in disablointi? Onko hyvä vinkki?

• "In Ubuntu 16.04 and in Linux Mint 18.x automatic TRIM is enabled by default, when you install Ubuntu 16.04 or Linux Mint 18.x on an SSD. Namely by a weekly "cron job". But in many (most?) cases, once a week isn't often enough, so I advise you to read on."
  • "Preferred method: daily by cron", onko tosiaan arempi kuin viikottain joka oletuksena?
  • fstrim:in käytöstä: "Note: on a few SSD models (specifically two models from Crucial), executing this command when there's high disk activity (I/O activity), might cause problems. So only apply it when there's not much activity going on. Preferably with all other applications closed." Kylläpäs kuulostaa tosi kätevältä, itsellä juuri tulossa käyttöön Crucial MX300. Ei tämä linux-maailma nyt kauhean helpolta näytä kun jatkuvasti tulee eteen uutta säädettävää ja tarkistettavaa.

• "Limit swap wear - On a scale of 0-100, the default setting is 60. Which is much too high for normal desktop use, and only fit for servers. For SSD's, it's just crazy." Joku taisi jo tästä aiemmin kirjoittaakin tänne.

• "Do NOT enable hibernation. Hibernation causes a huge amount of write actions, which is very bad for an SSD." Kuinka paha tämä nyt sitten on jos pakostikin joutuu käyttämään dual bootissa?

Samalla saitilla myös vinkataan erillisestä /home:sta näin:

Should I create a separate home partition?

2. No. I advise against a separate home partition: it only makes things more complicated, while offering no extra safety at all.

You always want an external backup of your documents, on an external device. A separate home partition is still part of the very same hard drive that all the other partitions are on. And they all die when the hard drive dies....

Plus you'll want to erase most of the old application settings anyway, before upgrading or re-installing. Because some of them may cause malfunctions in the new Ubuntu or Mint version.

The settings that you do want to keep, can easily be copied to an external device and then transferred back into a new installation.

Furthermore, a separate home partition means a non-optimal allocation of disk space, sometimes causing space shortage on either the root partition or the home partition. This is of course especially problematic on small hard disks.

Another disadvantage of a separate home partition is, that when you install multiple Linux distro's next to each other, your partition structure becomes very complex.

So a separate home partition often causes more trouble than ease of use....

Ihan hyviä muutamia pointteja tuossa ja en olekaan enää varma kannattaako erillinen osio tehdä homelle.

En ole käyttänyt btrfs:ää enkä täten itse tiedä kuinka sen koon muuttaminen jälkikäteen onnistuu. AInakin ext4:ssä kannattaa tässä tapauksessa käyttää LVM:ää joka lisää joustoa osioiden rakentumisen ja muuttamisen suhteen. Käsittääkseni btrfs toimii yhteen myös LVM:n kanssa mutta en tosiaan tiedä kuinka helppoa koon muuttaminen ilman sitä btrfs:ssä on.

Taas uusi tuttavuus, LVM, mitä nopeasti googlasin, niin eipä taida olla järkevä sitä käyttää koska ei pelitä dual bootissa Windowsin kanssa?

Laitan tässä vielä uudestaan Virtualboxiin dual boot-systeemin ja kokeilen Gpartedilla sörkkiä linuxin ja windowsin partitioita.

Snapshotit täytyy erikseen luoda, niitä ei luoda automaattisesti. Pöytäkäytössä en näe snapshotille hyötyä, vaan on hyödyllinen esim. NAS:ssa sen tarjoaman muutoshistorian vuoksi

Näinhän se taitaa olla, koneelta pitää kuitenkin ottaa versioiva backup NASsiin/etc.

Helpoin lienee olisi tosiaan kun teet yhden osion bootille, toisen itse käyttöjärjestelmälle ja kolmannen /homelle.

Dual bootissa windowsin asentaminen ensiksi taitaa automaattisesti tehdä EFI partition (ilmeisesti kyse on juuri tästä kun kirjoitat "bootista"?).

 

[keskiverto]

EFI partitio, ESP (EFI System Partition), on eri kuin 'boot'. Se mountataan /boot/efi ja sen tiedostojärjestelmä on FAT32. Sieltä löytyy boot loader(it).

/boot oli legacy BIOS:lla mielellään erillään, sillä BIOS haki sen alta boot loaderin. UEFI:n lukiessa ESP:tä /boot itsessään voi olla samaa tiedostojärjestelmää kuin /.

 

[Hammu]

EFI partitio, ESP (EFI System Partition), on eri kuin 'boot'. Se mountataan /boot/efi ja sen tiedostojärjestelmä on FAT32. Sieltä löytyy boot loader(it).

/boot oli legacy BIOS:lla mielellään erillään, sillä BIOS haki sen alta boot loaderin. UEFI:n lukiessa ESP:tä /boot itsessään voi olla samaa tiedostojärjestelmää kuin /.

Archin ohjeet ainakin neuvoo mounttaamaan ESPn /boot. Onko sillä mitään käytännön merkitystä, sitä en tiedä.

 

[TenderBeef]

- Pitääkö tähän vielä joku /boot osio tehdä? EDIT: edellisissä testeissä en erikseen mitään /boottia tehnyt ja tuntui ainakin toimivan.

- Mihin boot loader installoidaan? sda, sda2, sda6, kanada? EDIT: sama homma, en mitään erikseen valinnut tälle edellisissä testeissäni, taisi varmaan mennä silloin /sda:han.

Kokeilin tällä kertaa Mintin Cinnamonia (edellisissä testeissä eri topikissa XFCE (+Windows 10 Enterprise LTSB trial joka on nytkin) ja jouduin resetoimaan virtuaalikoneen joku 5 kertaa kun aina muutaman minuutin päästä kun live minttu oli auennut, koko järjestelmä meni jumiin ja CPU veisasi virsiä täysin palkein.. vähän rupeaa nyppimään, että onko linux minulle nyt ajankohtainen sittenkään..

 

[Hammu]

Ei pidä ja /dev/sda

 

[Xiyng]

Kokeilin tällä kertaa Mintin Cinnamonia (edellisissä testeissä eri topikissa XFCE (+Windows 10 Enterprise LTSB trial joka on nytkin) ja jouduin resetoimaan virtuaalikoneen joku 5 kertaa kun aina muutaman minuutin päästä kun live minttu oli auennut, koko järjestelmä meni jumiin ja CPU veisasi virsiä täysin palkein..

Cinnamonin toimivuus virtuaalikoneessa on ollut heikkoa ehkä Mintin versiosta 18 alkaen. Samoin vain vanhaa OpenGL-versiota tukevalla kannettavalla on ollut ongelmia. Ainakin Mate sen sijaan toimii moitteetta molemmissa.

vähän rupeaa nyppimään, että onko linux minulle nyt ajankohtainen sittenkään..

Mainittakoon, että omassa käytössäni vähempikin opettelu ja säätäminen on riittänyt. Tosin en ole käyttänyt Linuxia pääasiallisena käyttöjärjestelmänä säännöllisesti vaan joko pöytäkoneessa virtuaalikoneen kautta tai kannettavassa silloin harvoin kun kannettavaa tarvitsen, mutta äkkiseltään tuon voisi kuvitella vaikuttavan lähinnä osiointiin (jonka ei normaalikäyttäjällä tarvitse olla kovin monimutkaista). Pointtini on siis se, että riippuen toki tarpeistasi, saatat olla tekemässä asiasta ylipäänsä turhan vaikeaa.

 

[Barbarossa]

@TenderBeef

Miksi oikeastaan koet välttämättömäksi käyttää Btrfs:ää? Näihin Linuxin tiedostojärjestelmävalintoihin pätee vielä toistaiseksi vanha nyrkkisääntö: jos et varmasti tiedä tarvitsevasi tiettyä tiedostojärjestelmää, käytä ext4:ää. Toimivaksi todettu, kattaa kaikki peruskäytön tarpeet. En ole edellenkään vakuuttunut siitä että Btrfs tarjoaa koti/peruskäyttäjälle mitään lisäarvoa.

Ja mitä erilliseen /homeen tulee, itse en käytä sellaista koskaan ellei /home sijaitse fyysisesti eri levyllä kuin /. Mutta toisaalta, jos kokeilee eri distroja ja asentelee järjestelmää uusiksi tämän tästä voisin ymmärtää erillisen /homen käytön, kuten @8540 ylempänä jo totesikin.

"Access time stamp":in disablointi? Onko hyvä vinkki?

Tarkoittanee noatime-optiota. Tätä on käytetty aika yleisesti suorituskykysyistä jo ennen SSD-levyjä. Ilman tätä joka ikiselle tiedostolle talletetaan aikaleima joka kerta kun se avataan, myös lukiessa. SSD-levyllä disabloisin ehdottomasti, itse väänsin rutiininomaisesti pois päältä kaikista levyistä ennen SSD-aikakauttakin.

"Limit swap wear - On a scale of 0-100, the default setting is 60. Which is much too high for normal desktop use, and only fit for servers. For SSD's, it's just crazy." Joku taisi jo tästä aiemmin kirjoittaakin tänne.

Minä käytän tässä arvoa 1. Vanhassa läppärissä jossa on 4GB muistia, swappaukselta ei ole voinut täysin välttyä mutta uudemmassa jossa on 8GB en nyt parin kuukauden käytön aikana muista että olisin nähnyt swapin olleen käytössä kertaakaan.


Ja sitten vielä tapaus discard/trim. Tuossa aikaisemmassa läppärissä käytin jonkin aikaa fstabissa discard-optiota, mutta tämä aiheutti toisinaan esim. raskaampia käännöksiä tehdessä koko koneen hetkellisiä hyytymisiä.

Syynä tähän oli ilmeisesti se että kesken intensiivisen I/O-hyrskytyksen levy päätti alkaa suorittamaan jotakin roskienkeruuta joka blokkasi kaikki kirjoitusoperaatiot n. minuutiksi. Siirryin käyttämään joka yö klo 3.00 ajastettua fstrimiä discardin sijaan, ongelmat vähenivät huomattavasti. Uudessa laitoin suoraan ajastetun fstrimin.

 

[8540]

@keskiverto
EFI:n voi ainakin Archissa mountata huoletta /boot:iin. Itseasiassa ensin yritin mountata /boot/efi mutta en saanut konetta boottaamaan, ainakaan GRUB:ia käytettäessä. Kun vaihdoin sen vain /boot:iin niin kaikki pelitti kerrasta, joskin se itse generoi myös EFI kansion sen alle. On pelittänyt näin myös muilla koneilla mihin olen Archin asentanut, muut distrot ei ole käsipelillä tämän värkkäämistä vaatinutkaan.

Itsellä on salattu levy, täten käytän erillistä boot osiota oli se sitten UEFI tai BIOS bootattava. Eli itsellä /boot osio on salaamaton, joka sitten käynnistää käyttöjärjestelmän salatulta levyltä kysyen bootissa salasanaa.
Käsittääkseni ei ole merkitystä että onko se ESP nyt mountattu /boot vai /boot/efi jos distro sitä vain ymmärtää. Siksi varoitus että jotkin järjestelmät saattavat vaatia sen /boot/efi alle, mutta ei välttämättä. Paras toki katsoa sen oman distron dokumentaatiota miten se kuuluu tehdä jos eivät tue graafista asennusta.
Mutta se ESP partitio pitää olla jos boottaa UEFI:ssa, jolloin se ei voi olla samaa tiedostojärjestelmää / (rootin) kanssa, koska ESP on oltava FAT32. BIOS-bootatessa ei tarvita erillistä partitiota, paitsi jos haluaa käyttää salaamatonta boottia muutoin täysin salatulla levyllä, kuten itselläni. Lukiessani salatun bootloaderin käyttöä päätin että helpompi tie on tehdä erillinen /boot joka salaamaton. Tällöin myös salasana kysytään vain kerran.

@TenderBeef
noatime kannattaa tosiaan ottaa käyttöön, vähentää kirjoituksia ja täten pidentää SSD:n ikää. Tarkoittaa siis että aukaistessasi tiedoston sen aukaisun ajankohtaa ei kirjoiteta levylle kuten normaalisti. noatime = no access time.

Ei Linux-maailma helppo ole. Oppimiskäyrä on jyrkkä, verrattuna kaupasta ostettuun ja valmiiksi asennettuun järjestelmään (tosin Minttiä saa ulkomaan kaupoista, ja heillä on OEM installeri). Linuxit tulee niin monella eri konfiguraatiolla että ei se ikinä tule olemaan kovin helppo aluksi. Mutta kyllä tämä sinun tarinasi oikein yrittää olla vaikea asennettava. Jos haluat helpon Linuxin, asenna Mint käyttäen ext4:ää. Yksinkertaisempaa asennusta saa etsimällä etsiä. Tällöin asennus on helpompaa kuin Windowsissa. Toki Windowsin saa valmiina kaupasta, mikä on vielä helpompi. Mutta omasta mielestäni helppous ei aina tuo mukanaan sitä parasta järjestelmää, paras järjestelmä on se mikä on juuri minun halujeni mukaan tehty, jolloin toki sitten asennuskin on luokkaa vaikeampi. Onhan Linuxeja itsessäänkin satoja eri versioita.

Erillinen /home ei kiintolevyturvallisuuden kannalta eroa kuten tuolla linkkisi takana ehdotettiin, se vain yksinkertaistaa jos haluat vaihtaa toiseen distroon usein (.config filut voi manuaalisesti poistaa jos ne aiheuttaa ongelmia, pointti tässä on se että /home/Asiakirjat/ yms. säilyvät tallessa distrovaihdossa ilman bäkuppia) ja säilyttää /homen koskemattomana, tai jos boottaat OS:n SSD:ltä ja /home:n HDD:lta kuten minä. /home kun ei itsellä mahdu SSD:lle kun läppäri tuli niin pienen SSD:n kanssa. Tämän vuoksi läppärissä itselläni erillinen /home joka automaattisesti mountataan bootissa purkaen se crypttabilla automaattiseti avaintiedostoa käyttäen ja sitten liittäen fstabilla, pöytäkoneella ei ole erillistä /homea koska levy on tarpeeksi iso. Erillinen /home ei kannata jos aiot pysyä samassa distrossa yli kuukauden, sinulla on levyllä tarpeeksi tilaa eli et joudu jakamaan OS:ää ja /homea eri levyille ja et käytä salaamatonta OS:ää salatulla /home:lla. Tai jostain syystä eri tiedostojärjestelmää OS:n ja /home:n välillä. Jos mikään näistä ei kilahda kohdalle, ei erillinen /home kannata.

LVM pelittää moitteetta dual bootissa Windowsin kanssa. Windows ei toki sitä ymmärrä, mutta eipä se mitään muutakaan Linux-maailmasta ymmärrä (kuten ext4:ää, saati btrfs:ää) joten se ei aiheuta mitään muutosta. LVM ei sotke boottia mitenkään, muistaakseni Linux-maailma näkyy Windowsilla käyttämättömänä levytilana tjsp.. Itsellä on salauksen (dm-crypt) vuoksi LVM käytössä ja dual bootissa ei mitään ongelmaa. Ei Windowsilla sinne muutenkaan asiaa olisi. Linxuilta päin voi sitten sörkkiä Windowsin levyä jos siltä tuntuu.

Versioiva backup tulee helposti ohjelmalla "rdiff-backup", ilman snapshottia. Lienee btrfs:ssä sama kuin zfs:ssä että tarvitsee myös vastaanottavan systeemin olla samalla tiedostojärjestelmällä että snapshotin voi lähettää.
Btrfs ei ole yleensä suositeltu koska se ei ole kauaa vielä ollut edes vakaa ja siitä puuttuu useita ominaisuuksia ja se on varsin voimakkaan kehityksen alla. Se tulee olemaan kilpailija ZFS:lle jokin päivä, joten jos haluat btrfs:n ominaisuudet ja lisää päälle niin käytä ZFS:ää. Joskin OpenZFS:n lisensointi ei mätsää GPL:ään joten sen käyttöönotto on hieman hankalempaa Linux maailmassa (saat sen täältä, et suoraan distrolta: zfsonlinux.org), BSD:ssä heidän paljon väljemmän lisenssin takia se on tuettu out of the box. Btrfs tulee olemaan jokin päivä ZFS:n korvaaja Linuxilla lisensoinnin vuoksi, mikä lienee koko pointti sen kehittämisessä koska toiminnalisuudeltaan se vastaa ZFS:ää.
Työpöytäkäytössä en näe bit-rotin ehkäisyä mitenkään tärkeänä, ja jos sen bäkupin haluat tehdä versioivana niin snapshotaamisen voi mielestäni varsin hyvin korvata rdiff-backupilla. Se toimii kuten rsync mutta on versioiva.

Bootilla tarkoitan sitä missä sinun bootloaderisi on oli se mikä vain ja UEFI tai BIOS.
Windows tosiaan kannattaa asentaa ensin, yleisen suosituksen mukaisesti. Linux osaa helpommin kiertää toisen käyttöjärjestelmän sekoittamatta sitä. Windowsin asentaminen Linuxin jälkeen ei ole yhtä varmaa, kun jostain syystä Microsoft ei ole turhan innokas toisen käyttöjärjestelmän käytöstä.

Mitä tulee trimmiin niin:

Before SATA 3.1 all TRIM commands were synchronous, so continuous trimming would produce frequent system freezes. In this case, applying #Periodic TRIM less often is better alternative. Similar issue holds also for a number of devices, for which queued TRIM command execution was blacklisted due to serious data corruption. See Wikipedia:Trim (computing)#Shortcomings for details.

Eli poislukien tuollaiset laitteet sekä SATA 3.1:stä edeltävää standardia käyttävät laitteet pitäisi discard toimia, koska standardissa SATA 3.1 otettin käyttöön TRIM-jonotus. Tämä on siis standardin (ja joissain tapauksissa laitteiden) ongelma. Toki yleinen tapa on käyttää ajastettua fstrim:iä. Tämä queue TRIM:in käyttö vaikka se standardiin kuuluukin näyttää olevan usein/joissain levyissä poistettu käytöstä. Täten siis fstrim on varmempi vaihtoehto. Kokeilemalla varmasti selviää, saahan sen takaisinkin muutettua. Ei sitä järjestelmää laakista tarvitse juuri nappiin säätää vaan ajan kanssa voi viilailla.

Tässä lähteet joilla pärjää, näiden lisäksi muuta ei tarvita:
wiki.archlinux.org
wiki.gentoo.org
wiki.ubuntu.com

Jos nyt haluat asentaa sen järjestelmän ilman turhanpäiväistä pään seinään lyömistä niin suosittelen seuraavaa:
Asenna Windows
Asenna Linux, sinulla jos on Mint niin siinä helppo graafinen liittymä. Alat käyttämään ext4:ää ilman erillistä /home:a. Mint tekee sinulle bootloaderit yms. valmiiksi. Muistaakseni se myös tekee automaattisesti RAM:n kokoisen swapin, joten no worries.
Kun asennus on ohi ja olet bootannut Minttiin, suorita seuraava komento (xed on Mintin gedit, eli korvaa xed geditillä jos muuta distroa käytät):
sudo xed /etc/fstab
Tekstimuokkaimessa aukeaa nyt fstab, kun ensin syötät sille pääkäyttäjän salasanan. Siihen sitten oikealle riville lisäät option "noatime" pitäen muut as-is, eli pitäisi näyttää tältä (muu kuin noatime vain suuntaa antava esimerkki):
/dev/sdXy / ext4 defaults,noatime 0 1
/dev/sdXy on yleensä korvattu UUID-koodilla jolloin sen tilalla lukee "UUID=heksakoodilitania". UUID:n käyttö on suositeltavaa koska /dev/ lokaatiot voi muuttua jos pluggailet levyjä eri paikkoihin ajan saatossa. Myös Mintissä on oletuksena UUID käytössä.
Käsittääkseni Ubuntu-pohjaiset jakelut ottavat automaattisesti fstrim:n käyttöön jos levy sitä tukee. Trim-tuen voi itsekkin tarkistaa komennolla "lsblk --discard", jonka outputissa näkyvät DISC-GRAN ja DISC-MAX ollessa muuta kuin 0 tukee levysi trimmiä. Automaattinen trim fstrim:iä käyttäen tosiaan näyttäisi olevan Ubuntussa ja Mintissä automaattisesti käytössä, eli sinun ei tarvitse siitä huolehtia. En tiedä koskeeko tämä myös LVM-setuppia, luulisi, ainakin jos käytät sitä graafisen installerin checkboxia sen käyttöön.
Sitten mennään siihen versioivaan backuppiin:
sudo apt install rdiff-backup
Teet sille sitten cronjobin halutulla ajastuksella, johon löytyy ohjeita mm. näistä paikoista:
Cron - ArchWiki
Crontab Syntax Tutorial - Linux Mint Community
CronHowto - Community Help Wiki
Cronjobiin tulee komento joka käyttää rdiff-backupia. En tiedä setuppiasi, mutta esim. täällä on selkeät ohjeet:
rdiff-backup – Linux.fi
Täys manuaali:
rdiff-backup(1) - Linux man page
Eli vaikkapa tunnin välein versioiva backup kotikansiosta verkkojakoon joka mountattu /mnt/varmuuskopio, poistaen viikoittain (lauantai klo 10:30) yli 30 päivää (30D) vanhat versioinnit:
En itse tykkää vimistä, vaan nanosta, joten vaihdetaan editori:
EDITOR=nano crontab -e
Eli formaatti on "minuutti tunti kuukauden_päivä kuukausi viikonpäivä komento" ja kaikki ilmoitetaan numeroina. * tarkoittaa mitä tahansa.
0 * * * * rdiff-backup /home /mnt/varmmuskopio
30 10 * * 6 rdiff-backup --force --remove-older-than 30D /mnt/varmuuskopio

Edit: Cronjobille on myös graafinen editori nimeltään gnome-schedule:
Schedule - GNOME Wiki!
Tuon jos asennat niin ei tarvitse lähteä komentolinjalta cronjobia tekemään. Ja pitäisi löytyä käytännössä joka distron paketinhallinnasta, eli Mintillä:
sudo apt install gnome-schedule
Tai sitten käynnistät Mintin ohjelmistohallinnan ja sieltä kivasti graafista nappia painat.

Swapin säätö menee Mintissä täten:
sudo xed /etc/sysctl.conf
Etsi löytyykö riviä jossa lukee "vm.swappiness", jos löytyy viilaa sen perässä oleva numero arvoon 10 kuten minulla, tai 1 kuten @Barbarossa
Jos ei löydy, lisää sinne:
vm.swappiness = 10
tai
vm.swappiness = 1
Tai minkä swappausherkkyyden haluatkaan. Tämä uusi asetus on voimassa rebootin jälkeen.


Minun /boot ohjeeni olivat archille, Mintissä niille ei pitäisi olla mitään käyttöä kun se tekee kaiken automaattisesti, ja jos käytät ext4:ää, ei sinun tarvitse lähteä itse osioimaan mitään, kunhan varmistat että siellä on riittävästi tilaa Windows-asennuksen jälkeen.

Omasta mielestäni ylläoleva pitäisi vastata tarpeisiisi vähentäen mielestäni turhaa toimintaa, kuten btrfs:n käyttö. Toki jos sitä vartavasten haluat käyttää niin eihän siinä, senkus, mutta silloin asennuksen vaikeustaso nousee tasolle jota en ole koskaan itse läpi käynyt.

 

[Pertti Kosunen]

Googlasin vähän ja tuon "discardin" käyttöä ei suositella enää. Esim. täällä, jossa myös muitakin (päteviä?) huomioita/vinkkejä:

Tuo on minusta turha pelko, ei se mitenkään merkittävästi hidasta perus työpöytä-käytössä ja harvalla on enää noita trim-tuettomia levyjä. Toki discard päälle vain yhteensopivien tiedostojärjestelmien kanssa. (Jonotettu trim ei toimi kaikkien levyjen kanssa kunnolla, mutta tuon kernel osaa yleensä ottaa tarvittaessa itse pois päältä.)

CFQ scheduler on tukenut jo pitkään "pyörimättömiä" levyjä ja on lähes kaikessa nopeampi perus-SSD:n kanssa kuin deadline, se osaa mm. optimoida kirjoitusjonot säikeittäin. Supernopeat NVMe levyt on nopeimpia ilman scheduleria eli none/noop kanssa.

Kirjoitusten optimoinnit ja uni-tilan poistot jne. on enimmäkseen huuhaata, nykylevyt kestävät kymmeniä tai satoja vuosia solujen kulumisen puolesta joten käyttötapoja on turha muuttaa tai hidastaa säästöjen vuoksi (Firefoxin session tallennusväli ehkä poikkeuksena, se voi olla turhan agressiivinen).

Noatime onkin jo kerrottu, lukuaikojen tallennusta en ainakaan itse tarvitse mihinkään.

Archin ohjeet ainakin neuvoo mounttaamaan ESPn /boot. Onko sillä mitään käytännön merkitystä, sitä en tiedä.

Tuolla tavalla grubin moduulit jne. ja kernelit menee EFI-käynnistysosiolle tarpeettomasti, sinne ei tarvitse kuin pelkän grub*.efi tiedoston eli bootloaderin (ellei käytä salausta).

 

[Stanley H. Tweedle]

Mintin/*ubuntun jne. ainoa tarpeellinen tweakkaus modernilla kalustolla default-asennuksen jälkeen on swappinesin säätö.

Ei se nyt niin vaikeaa ole, jos ei vartavasten halua tehdä vaikeasti.

 

[8540]

Tuolla tavalla grubin moduulit jne. ja kernelit menee EFI-käynnistysosiolle tarpeettomasti, sinne ei tarvitse kuin pelkän grub*.efi tiedoston eli bootloaderin (ellei käytä salausta).

Aivan, tämän takia minulla lienee ei toiminut mountatessa /boot/efi. Enpä tullut tosiaan ajatelleeksi että kerneli menee silloinkin normaalisti vain /boot ja täten olisi salauksen takana estäen boottaamisen säätämättä grubia toimimaan salattuna. Olenkin miettinyt mistä tuo johtui. Harvalla on koko levy salattuna niin sillä tulee itse yleensä hieman sovellettua asioita (kuten se erillinen /boot myös bios-bootissa), kun en itse ole käyttänyt salaamatonta järjestelmää kuin Windowsille sitten vuoden 2012 tjsp..

 

[keskiverto]

EFI:n voi ainakin Archissa mountata huoletta /boot:iin.

Eli iloisesti on distro-kohtaisia eroja siihen, miten asiat tehdään.

noatime kannattaa tosiaan ottaa käyttöön, vähentää kirjoituksia ja täten pidentää SSD:n ikää. Tarkoittaa siis että aukaistessasi tiedoston sen aukaisun ajankohtaa ei kirjoiteta levylle kuten normaalisti. noatime = no access time.

Red Hat-pohjaisilla distroilla on 'relatime' oletuksena päällä. Lähinnä laiska atime.