SSd-levyt ja kirjoituskerrat

[spark]

Kannattaisikohan jotain tehdä kestävyyden kannalta, kun tässä 120GB SSD levylle olen manuaalisesti trimmauksen tehnyt noin kerran viikossa komennolla: sudo fstrim -v /

Lähes järjestäen on trimmattavaa ollut yli 10GB edestä. Tuo määrä tulee nettisurffailusta ja Steam pelien pelaamisesta.

Entä olisiko levylle järkevää tehdä jokin ylimääräinen levytarkistus sähkökatkon tms. jälkeen?

[Postimies]

Kannattaisikohan jotain tehdä kestävyyden kannalta, kun tässä 120GB SSD levylle olen manuaalisesti trimmauksen tehnyt noin kerran viikossa komennolla: sudo fstrim -v /

Lähes järjestäen on trimmattavaa ollut yli 10GB edestä. Tuo määrä tulee nettisurffailusta ja Steam pelien pelaamisesta.

Entä olisiko levylle järkevää tehdä jokin ylimääräinen levytarkistus sähkökatkon tms. jälkeen?

Eikös Ubuntu tee tuon fstrimin ajastetusti? Itsellä yksi kone jossa fstrimmiä ei ole ikinä ajettu. fstab-tiedostossa on optiot discard,noatime. En ole huomannut muutokia nopeudessa. Toisessa koneessa missä Ubuntu liki asennuksen jäljiltä ei muutosta yli puolen vuoden jälkeen. Voisi kokeeksi katsoa shh:lla, mutta ei käynnissä nyt.

Yleensä kone huomaa levyn kirjanpidosta jos sitä ei ole sammutettu oikein ja tarkistaa levyn.  tune2fs ohjelmalla voit säätää kuinka usein levysi tarkistetaan. Ja monia muita parametreja.

[raimo]

Eikös Ubuntu tee tuon fstrimin ajastetusti? Itsellä yksi kone jossa fstrimmiä ei ole ikinä ajettu. fstab-tiedostossa on optiot discard,noatime. En ole huomannut muutokia nopeudessa. Toisessa koneessa missä Ubuntu liki asennuksen jäljiltä ei muutosta yli puolen vuoden jälkeen. Voisi kokeeksi katsoa shh:lla, mutta ei käynnissä nyt.

Yleensä kone huomaa levyn kirjanpidosta jos sitä ei ole sammutettu oikein ja tarkistaa levyn.  tune2fs ohjelmalla voit säätää kuinka usein levysi tarkistetaan. Ja monia muita parametreja.

discard optio /etc/fstab tiedoston rivillä aikaansaa trim:in
http://en.wikipedia.org/wiki/TRIM
Vaihtoehtona on sitten fstrim esim. Cron:n ajamana, molempia ei liene tarvetta käyttää.

[Postimies]

discard optio /etc/fstab tiedoston rivillä aikaansaa trim:in
http://en.wikipedia.org/wiki/TRIM
Vaihtoehtona on sitten fstrim esim. Cron:n ajamana, molempia ei liene tarvetta käyttää.

Tarkistin. TRIM ei ole oletuksena päällä Ubuntussa (14.04). discard optio toimiii hieman samoin kuin Windows tekee, mutta hitaammin. Suositus on käyttää fstrim komentoa. XFS-tiedostojärjestelmä tukee myös Trimmiä. Itse tykkään siitä (historiallisista syistä).  Historiallisista syistä Ext4 varaa 5% levytilasta "rootille", mikä on nykyisillä levyillä turhan paljon. Isommat levyt olen pistänyt XFS-tiedostojärjestelmälle jo vuosia. Ja aina harmittaa kun Ubuntu ei tunnista niitä oikein asennuksessa. Xfsprogs pitää aina asentaa erikseen.

[Tomin]

XFS-tiedostojärjestelmä tukee myös Trimmiä. Itse tykkään siitä (historiallisista syistä).  Historiallisista syistä Ext4 varaa 5% levytilasta "rootille", mikä on nykyisillä levyillä turhan paljon.

Tuo 5% varaus on harvinaisen huono syy vaihtaa tiedostojärjestelmää. Sitä voi säätää tune2fs-komennolla. Toki on muita hyviä syitä (joskus) valita XFS Ext4:n sijaan. Itsekin käytän sitä MythTV:n kanssa, joka siis tallentaa TV-ohjelmia kiintolevylle.

Koodia: [Valitse]

sudo tune2fs -m 1 osion_laitetiedostoSäätää ko. osiolle varattujen lohkojen määrän prosenttiin. Sen voi myös säätää nollaan lohkoon:

Koodia: [Valitse]

sudo tune2fs -r 0 osion_laitetiedostoTai sitten mihin haluaa. Lisätietoja tune2fs:n man-sivu ja http://linux.fi/wiki/Tune2fs

[raimo]

Ubuntussa (14.04) on fstrim-all paketti:
http://manpages.ubuntu.com/manpages/trusty/en/man8/fstrim-all.8.html
Jonka pitäisi kai ajaa cron:n kanssa fstrim kaikille liitetyille SSD-osioille.
En kuitenkaan saanut sitä toimimaan OCZ Vertex 460 SSD:n kanssa.
Bash-skripti cronin ajamana hoitelee nyt fstrim-hommat kerran vuorokaudessa.

[Postimies]

Tuo 5% varaus on harvinaisen huono syy vaihtaa tiedostojärjestelmää. Sitä voi säätää tune2fs-komennolla. Toki on muita hyviä syitä (joskus) valita XFS Ext4:n sijaan. Itsekin käytän sitä MythTV:n kanssa, joka siis tallentaa TV-ohjelmia kiintolevylle.

Syy ei ole 5% varaus, vaan lähinnä levyjen tarkistukseen kuluva aika ja tiedostojärjestelmän valinta vuosia sitten (se historiallinen syy). XFS on ollut kauemmin vakaa kuin ext4. Esim. juuri tv-tallenteiden kanssa valinta xfs vs ext3 välillä on helppo. ext4:ssä tiedostojärjestelmän tarkistus on nopeutunut, mutta silti voi kestää melko kauan tietyissä tilanteissä. e4defrag ohjelmaa en myöskään ole käyttänyt ikinä.

[Sami Lehtinen]

XFS on ollut kauemmin vakaa kuin ext4. Esim. juuri tv-tallenteiden kanssa valinta xfs vs ext3 välillä on helppo.

Ext3:n kanssa deletoinnit ja levyjen tarkistukset oli järkyttävän hitaita. Syy kai siihen miksi discardia ei suositella on se, että TRIM komentoja ei voi nykyisellään pistää jonoon / rinnan. Mutta käsittääkseni tuo on korjattu joissain uudemmissa hardiksissa / firmiksissä, en sitten tiedä onko Ubuntussa tukea moiselle.

Ext4:n kanssa en ole kokenut olevan mitään niin isoja drawbackkeja, että olisi mitään syytä haikailla toisten tiedostojärjestelmien perään. No ehkä Inliningin puute oletuksena voi olla sellainen. Mutta eikös toi BtrFs ole jo hyvää vauhtia tulossa.

Koska tämä on nyt kuitenkin SSD-ketju, niin herätetään kysymys SSD-tiedostojärjestelmistä. Noista luin jossain vaiheessa paljon, bloggasin jne. Mutta nykyisissä levyissä on niin hyvät trimmit ja sisäinen kirjanpito, että SSD-tiedostojärjestelmä vaikuttaa sinänsä aika turhalta. Toinen juttu on tietysti jotkut tosi low-end embedded deviced jossa SSD:tä käytetään raakana ilman FTL:ää. Kuten esim. jotkut käynnykät jne.

[Postimies]

Ext4:n kanssa en ole kokenut olevan mitään niin isoja drawbackkeja, että olisi mitään syytä haikailla toisten tiedostojärjestelmien perään. No ehkä Inliningin puute oletuksena voi olla sellainen. Mutta eikös toi BtrFs ole jo hyvää vauhtia tulossa.

Ext4 ihan hyvä SSD levylle. Tarkistuskin menee nopeasti kun on nopea. Isolla ja hitaalla levyllä tarkistus kestää.... Itse vihaan sitä jos joutuu pitkään odottamaan levyn tarkistusta. Inliningin puute minulle vieras termi....

[Sami Lehtinen]

Inliningin puute minulle vieras termi....

Data Inlining tarkoittaa sitä, että pienille tiedostoille ei varata omia blokkeja ollenkaan, vaan tiedoston sisältö kirjoitetaan suoraan metadataan / hakemistorakenteeseen mukaan.

Eli käytännössä silloin ei ole eroa tallennanko
tiedosto_tässä_on_dataa.dat nimisen tiedoston vai
tallennanko tässä_on_dataa "tiedosto" nimiseen tiedostoon.

Ratkaisuissa joissa inlining ei ole käytössä, jälkimmäinen esimerkki allokoi 4 kilon blokin, kun taas tiedostojärjestelmissä joissa inliningin kanssa näin ei käy. Erittäin tärkeä feature pikkutiedostojen kanssa.

Btw. Tuo on mahdollista kääntää ext4:lla päälle, mutta pitäisi määritellä formatointi vaiheessa ja silloinkin maksimi koko joka tuonne rakenteeseen mahtuu oli muistaakseni varsin rajallinen. Joskin ihan riittävä tosi pieniä tiedostoja varten. (~100 tavua tms).

[Postimies]

Data Inlining tarkoittaa sitä, että pienille tiedostoille ei varata omia blokkeja ollenkaan, vaan tiedoston sisältö kirjoitetaan suoraan metadataan / hakemistorakenteeseen mukaan.

Ratkaisuissa joissa inlining ei ole käytössä, jälkimmäinen esimerkki allokoi 4 kilon blokin, kun taas tiedostojärjestelmissä joissa inliningin kanssa näin ei käy. Erittäin tärkeä feature pikkutiedostojen kanssa.

Btw. Tuo on mahdollista kääntää ext4:lla päälle, mutta pitäisi määritellä formatointi vaiheessa ja silloinkin maksimi koko joka tuonne rakenteeseen mahtuu oli muistaakseni varsin rajallinen. Joskin ihan riittävä tosi pieniä tiedostoja varten. (~100 tavua tms).

ReiserFs sisältää tuon ominaisuuden. En tiennyt että tuollainenkin mahdollisuus on. Nopeuttaisi varmasti esim. Gentoon portagen käyttöä, jossa paljon pieniä tiedostoja.
100 tavua on kyllä vähän.

[Sami Lehtinen]

ReiserFs sisältää tuon ominaisuuden.

Reiser taisi olla ensimmäinen tiedostojärjestelmä jonka mä tiedän tuota käyttäneen. Mutta varmaan, kuten yleensä, niin ominaisuus on varmaan ollut jonkun ison lafkan proprietary systeemeissä tosi pitkään. On aina yhtä hauskaa huomata, että se 'uusi juttu', on todellisuudessa helposti vuosikymmeniä vanha juttu. Harvoin keksitään mitään ihan oikeasti uutta.

Tämä ext4 inline data patchi on käsittääkseni nykyjään ihan vakkarina tarjolla. Tuolla se luki 132 tavua oli tarkempi arvo, jota en muistanut. Tämä siis ext4:lla, tietyissä olosuhteissa.

[Hajakenttä]

Aika pitkään on ollut tämä Asus eee-pc SSD-muistilla käytössä, kuudetta vuotta jo, mutta kun ei mene rikki niin jatketaan.

Onkohan se huono valinta kun laitoin jo 12.04 aikaan järjestelmäksi ext2:n? Se kun ei tee kirjanpitoa niin ajattelin sen säästävän tätä vanhaa SSD muistia, joka lienee niitä ensimmäisiä kauppoihin tulleita. Ainakin se/ne ovat pieniä kapasiteetiltaan. Nopeampi 3,5 GiB ja ei niin nopea 15 GiB.

Tuosta edeltä sain käsityksen, että 14.04 ei tee niitä levyntarkastuksia, joita vielä 12.04 teki harvakseltaan. Olenko käsittänyt oikein?

Kun päivittämällä (ei asentamalla) uudistin 12.04 > 14.04 tapahtui ensimmäisellä uudelleenkäynnistyksellä levyntarkastus. Sen huomasi selvästi. Sen jälkeen ei ole tarkastettu. Kun katsoin komennolla:

Koodia: [Valitse]

sudo dumpe2fs -h /dev/sda1(ja sama osioille sdb1 ja sdb5 jotka ovat myös käytössä) niissä kaikissa näkyi: Check interval: 0 (<none>). Onko tuo se, joka määrää tarkastusvälin? Siellä oli myös viimeinen tarkastus tarkalleen se päivityksen jälkeinen uudelleenkäynnistyksen aika. Seuraavaa tarkastusta varten ei ollut edes riviä. Myöskin niissä on rivi:Filesystem state: not clean. Pitäisikö tuosta olla huolissaan ja asettaa joku tarkastus intervalli? Millä komennolla sitä pääsee muokkaamaan?

Siellä näkyy myös rivi: Block count: ja luku perässä. Jos tuota lukua seuraa, kertooko se levyn kulumisen, eli pieneneekö se?

Onko tässä asiassa hyötyä tästä komennosta?

Koodia: [Valitse]

fstrim-allSe ei näy tekevän mitään. Ei anna kyllä mitään virheilmoitustakaan, mutta edelleen on Filesystem state: not clean. Pitäisikö sen olla 'fstrim-all --no-model-check' vai peräti 'sudo' edessä? Ihan kaikkea en uskalla kysymättä koittaa kun olen niin usein saanut koneen sutturalle. Tuonhan voisi sitten ajoittain komentaa, jos mieleen juolahtaa, ja uskaltaa.

Tuttavan Linux-konetta olen myös pitänyt iskussa. Siinä on pyörivä (käkikelloajan) kovalevy. Päteekö nämä 'dumpe2fs' ja 'fstrim' komennot myös sellaisiin vai vain SSD-levyihin? Siinäkään koneessa ei levyntarkastuksia ole esiintynyt sen jälkeen kun uusittiin Ubuntu asentamalla puhtaana asennuksena 14.04.

[kamara]

Onkohan se huono valinta kun laitoin jo 12.04 aikaan järjestelmäksi ext2:n?

Itse käytän samanlaisessa koneessa ext4:sta. Tosin se on tällä hetkellä vain matkakoneena.

Hitaan 16 Gt:n laitoin juureen ja "nopean" 4 Gt:n homeksi. Koneessa on Lubuntu 14.04.

Ratkaisu, koska 4 Gt on liian vähän juurelle, jos ei viitsi säätää.

[nm]

Kun päivittämällä (ei asentamalla) uudistin 12.04 > 14.04 tapahtui ensimmäisellä uudelleenkäynnistyksellä levyntarkastus. Sen huomasi selvästi. Sen jälkeen ei ole tarkastettu. Kun katsoin komennolla:

Koodia: [Valitse]

sudo dumpe2fs -h /dev/sda1(ja sama osioille sdb1 ja sdb5 jotka ovat myös käytössä) niissä kaikissa näkyi: Check interval: 0 (<none>). Onko tuo se, joka määrää tarkastusvälin?

Check interval määrää tarkastusvälin ajassa. Lisäksi tiedostojärjestelmässä on asetus tarkistuksille liitosten määrän mukaan (maximum mount count). Esimerkiksi omalle juuriosiolleni dumpe2fs näyttää tällaista:

Koodia: [Valitse]

Mount count:              7
Maximum mount count:      34

Levytarkistus on siis tässä järjestelmässä edessä, kun kone on käynnistetty uudelleen vielä 27 kertaa.

Myöskin niissä on rivi:Filesystem state: not clean. Pitäisikö tuosta olla huolissaan ja asettaa joku tarkastus intervalli? Millä komennolla sitä pääsee muokkaamaan?

Filesystem state: not clean on huono merkki, eli tiedostojärjestelmässä on jotain häikkää. Levy kannattaisi tarkistaa fsck:lla, ja juuriosion tapauksessa se onnistuu parhaiten asettamalla jokin tarkistusintervalli tai maximum mount count.

Sekä check intervallia että maximum mount countia voi säätää tune2fs:llä. Esimerkki: asetetaan osion sda1 tarkistusväliksi kaksi kuukautta tai 40 liitoskertaa:

Koodia: [Valitse]

sudo tune2fs -i 2m -c 40 /dev/sda1

Siellä näkyy myös rivi: Block count: ja luku perässä. Jos tuota lukua seuraa, kertooko se levyn kulumisen, eli pieneneekö se?

Block count on blokkien lukumäärä osiolla eli se kertoo tiedostojärjestelmän koon (Block size * Block count = tiedostojärjestelmän koko tavuina). Tämä ei muutu mihinkään ellet muuta osion ja tiedostojärjestelmän kokoa. Levyn tilasta kertovia määreitä, eli esimerkiksi uudelleensijoitettujen sektorien lukumäärää, voi seurata smartctl:llä, jos levy tukee S.M.A.R.T.-järjestelmää. Lähes kaikki SATA-levyt ja uudemmat PATA-levyt tukevat sitä, mutta tuo EeePC:n SSD-levy voi olla poikkeustapaus. Muutenkin SMART-tietojen tulkinta on aika hankalaa ja levykohtaista.

Onko tässä asiassa hyötyä tästä komennosta?

Koodia: [Valitse]

fstrim-allSe ei näy tekevän mitään.

fstrim-all suorittaa TRIM-operaation kaikilla liitetyillä levyillä, jotka tukevat sitä. Vanhempien EeePC-läppäreiden SSD:t eivät tietääkseni tue trimiä.

Tuttavan Linux-konetta olen myös pitänyt iskussa. Siinä on pyörivä (käkikelloajan) kovalevy. Päteekö nämä 'dumpe2fs' ja 'fstrim' komennot myös sellaisiin vai vain SSD-levyihin? Siinäkään koneessa ei levyntarkastuksia ole esiintynyt sen jälkeen kun uusittiin Ubuntu asentamalla puhtaana asennuksena 14.04.

dumpe2fs ja tune2fs ovat yleisiä ext2/3/4-tiedostojärjestelmien työkaluja. Ne toimivat kaikilla levytyypeillä. fstrim toimii vain SSD-levyillä, jotka tukevat TRIMiä.

[Hajakenttä]

Kiitos vastauksista. 

[Hajakenttä]

Muutin tuota tarkastusintervallia niin, että se oli yhtä suurempi kuin tehdyt käynnistykset. Kun sitten tein sammutuksen ja käynnistyksen tuli käynnistyksen alussa noin sekunnin ajaksi teksti (sitä tylsää valkoista muuten mustan ruudun ihan yläreunassa kaksi riviä) "System failed..." ja muuta en ehtinyt lukea. Sitä ei yleensä ilmaannu normi käynnistyksessä. Epäilen sen ilmoittaneen juuri tarkastuksen käynnistyksen epäonnistumisesta, mutta en ole varma. Ainakaan mitään tarkastukseen viittaavaa ei näkynyt. Ennenhän oli Xubuntun käynnistyksessä sinisen ruudun alareunassa selvä suomenkielinen ilmoitus tarkastuksesta ja palkki, joka kertoi sen edistymisestä.

Koodia: [Valitse]

sudo dumpe2fs -h /dev/sda1
Tuo kyllä kertoi, että tarkastusväli on se, joksi sen asetin, ja sen, että viimeinen tarkastus on tehty tänään, ja sen, että Filesystem state: not clean. Joka siis on edelleen sama kuin ennenkin, joka hiukan huolestuttaa. Kaikki kuitenkin toimii, mutta kuinka kauan? 

Onko joku komento, jolla levyn not clean tila voisi olla korjattavissa?

Vai voisiko olla kysymyksessä vain järjestelmän "erehdys" siitä johtuen, että tällä koneella on hiukan normaalista poikkeava levyjen ja osioiden järjestely, Kamarankin mainitsemasta EeePC koneiden liian pienestä sda:sta johtuen?

Tässä on käynnistyslatain sdb1 osiolla olevalla / kernel-osalla ja sdb5 osiolla /home. sda1, jolla kernel normaaalisti olisi, onkin nyt 3,5 GiB;n /usr ja sen sisältämät sovellukset ym. koska siihen eivät kernel ja sovellukset yhdessä mahdu. Olen pitänyt tätä, täältä oppimaani, järjestelyä nerokkaana  koska nyt koko muuten ahdas ssd tulee hyvin käytetyksi ja riittää mainiosti.

[raimo]

Levyn tarkistuksen voi pakottaa näin:

Koodia: [Valitse]

sudo touch /forcefsckFsck ajetaan seuraavassa bootissa, tiedosto poistuu itsestään.

[nm]

Lisäksi joudut todennäköisesti pakottamaan tiedostojärjestelmän korjaukset /etc/default/rcS -tiedoston avulla. Muokkaa sitä pääkäyttäjän oikeuksin jollain tekstieditorilla:

Koodia: [Valitse]

# automatically repair filesystems with inconsistencies during boot
FSCKFIX=no
-->

Koodia: [Valitse]

# automatically repair filesystems with inconsistencies during boot
FSCKFIX=yes

[Hajakenttä]

Levyn tarkistuksen voi pakottaa näin:

Koodia: [Valitse]

sudo touch /forcefsckFsck ajetaan seuraavassa bootissa, tiedosto poistuu itsestään.

Kokeilin tuota. Arvaan, että tarkastusta ei tapahtunut. Sama virheilmoitus vilahti edelleen. Sellainen hassutus kyllä esiintyi, että heti sen virheilmon jälkeen tuli GUB-valikko näkyviin. Siis toisen kerran. Tuota ei ennen ole tapahtunut. Olen säätänyt GRUB-valikon näkymään sekunnin, ja niin se olikin, mutta heti tuon virheilmon jälkeen se tuli uudelleen ja oli ainakin 15 sekuntia, en jaksanut pitempään odottaa, ja sitten enterin jälkeen virheilmoituksia ei enää tullut ja muuten käynnistyminen tapahtui ihan normaalisti ja nopeasti.

Not clean - tila näkyy edelleen levyn tiedoissa

Tuanoinnii... tekeekö tuo fsck muuta kuin tarkastuksen? Merkkaako se myös vikapaikat secundaksi, jota ei enää käytetä, ja joka on sitten pois levytilan kokonaismäärästä? Siitä ssd-muistin kulumisestahan tässä oikeastaan on tarkoitus keskustella.

P.S. Ahaa... tuossa taisi tulla lisätietoa tätä kirjoittaessa. Opettelen lisää...