Ubuntu Suomen keskustelualueet

Muut alueet => Yleistä keskustelua => Aiheen aloitti: Tuxer - 20.05.13 - klo:15.36

Otsikko: SSd-levyt ja kirjoituskerrat
Kirjoitti: Tuxer - 20.05.13 - klo:15.36
Asensin ssd-levyn (Kingston 120Gt) ja samalla Debianin suoraan levylle eli niin että /home oli myös ssd-levylllä. Ja kylläpä kaikki toimi nopeasti, ohjelmat käynnistyivät *heti*. Mahtavaa!

Mutta, sitten siirsin /home:n vanhalle kovalevylle ja nyt sitten tuli harmittava parin sekunnin viive selaimen käynnistymiseen. Tiedän, ei ole paljon mutta kun ehti nähdä sen viiveettömänkin käynnistymisen.

Kysymys siis on: Onko nykyisillä SSD-levyillä enää merkitystä luku/kirjoituskerroilla. Selain kirjoittelee aika paljon ja nyt ne eivät mene SSD-levylle. Mutta onko tällä enää nykyisin merkitystä? Levyllä kuitenkin luvataan viiden vuoden takuu...

Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: CoReD - 20.05.13 - klo:17.09
Itse, henkilökohtaisesti, en juuri jännittäisi normaalissa käytössä olevan kotikoneen SSD:n eliniän puolesta.. Ei näitä nykyaikaisia SSD:tä enää normaalikäytöllä hetkessä hajoteta.

Itselläni on / ja /home molemmat SSD:llä, mutta itsekkin olen joitain toimenpiteitä tehnyt SSD:tä säästääkseni, lähinnä varmuuden välttämiseksi.

Helppoja kikkoja esim: noatime optiot levyosioille, swap jonnekkin muualle kuin ssd:lle ja selaimen (ja muiden tiuhasti kirjoittavien ohjelmien (esim. spotify on myös melko ahkera kirjoittaja)) väliaikaistiedostot tmpfs:sään.

Täällä: http://forum.ubuntu-fi.org/index.php?topic=15417.0

on meikäläisen kirjoittama lyhyt ohje tmpfs:stä, fstabista (noatime, commit) ja chromen väliaikaistiedostoista - josta voi ainakin vähän osviittaa hakea virittelyihin jos tmpfs ja fstab on ihan vieraita juttuja. :)
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: kamara - 20.05.13 - klo:17.15
Minulla on sellainen tuntuma, että SSD-levyt kestävät ainakin sen mitä tavallisetkin levyt.

Vai onko kellään hajonnut SSD-levyä. Itselläni on hajonnut kaksi muistitikkua, yksi SDHC-kortti ja ainakin kaksi kiintolevyä, muttei yhtään SSD-kiintolevyä.

Omistan tällä hetkellä 4 SSD-levyä, ja olen myynyt yhden käytetyn SSD-levyn, jossa siinäkään ei ole mitään ongelmia esiintynyt.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: petteriIII - 20.05.13 - klo:17.40
Niin on minunkin SSD:ni ollut kovilla jo kaksi vuotta; dataa siirtyy päivittäin useampi gigatavu. Boottauksiakin päivittäin useita, joskus väkivalloinkin kun ohjelma hirttää kiinni eikä "kerkiä" sammuttamaan REISUB:illa. Pikkuisen kone jo kiukuttelee, mutta toimii sittenkin melkohyvin. Ehkä olisi jo aika vaihtaa SSD ennenkuin se hajoaa - mutta käyttöni onkin kymmeniä kertoja kuluttavampaa SSD:lle kuin normaali käyttö. Nopeus ei ole mielestäni laskenut.

- ja varsin halpa se oli SSD:ksi.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Mese - 20.05.13 - klo:18.47
SSD-levy ollut käytössä jo kolmisen vuotta ilman ongelmia.
SSD-levyllä vain /-osio, /home- ja swap-osiot tavallisella kovolla.

TRIM-toiminto kannattaa kyllä ottaa käyttöön.

Toinen asia on tietenkin osioiden oikea kohdistus.

Oheisissa linkeissä aika hyvät ohjeet SSD:n käyttöönottoon:

http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm (http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm)

http://lifehacker.com/5837769/make-sure-your-partitions-are-correctly-aligned-for-optimal-solid-state-drive-performance (http://lifehacker.com/5837769/make-sure-your-partitions-are-correctly-aligned-for-optimal-solid-state-drive-performance)

Sorry, jos nämä asiat olivat jo ennalta selviä!  ;D
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: qwertyy - 20.05.13 - klo:21.09
Kysymys siis on: Onko nykyisillä SSD-levyillä enää merkitystä luku/kirjoituskerroilla.
Tästä löytyy tältäkin foorumilta vaikka kuinka paljon juttua.

Lyhyt vastaus: Ei ole
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Tuxer - 20.05.13 - klo:23.00
Kiitos vastauksista, tuossa tuli aikamoinen tietopaketti.

noatime ja väliaikaistiedot muistiin näyttäisi olevan ainakin temppuja jotka kannattaa tehdä.  Kokeilen myös vaihtaa scheduleria Mesen linkin mukaan, eipä ollut tietoa tuostakaan.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Mese - 21.05.13 - klo:07.58
Kiitos vastauksista, tuossa tuli aikamoinen tietopaketti.

noatime ja väliaikaistiedot muistiin näyttäisi olevan ainakin temppuja jotka kannattaa tehdä.  Kokeilen myös vaihtaa scheduleria Mesen linkin mukaan, eipä ollut tietoa tuostakaan.

Ubuntu 13.04:ssä on schedulerina oletusarvoisesti deadline, joka käy hyvin SSD:lle.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Aatos Rapula - 21.05.13 - klo:12.32
Minulla on sellainen tuntuma, että SSD-levyt kestävät ainakin sen mitä tavallisetkin levyt.

Vai onko kellään hajonnut SSD-levyä.

Tällaiseen uutiseen törmäsin eilen:
http://www.3t.fi/artikkeli/uutiset/teknologia/uudet_ssd_tallennuslevyt_ovat_petollisia (http://www.3t.fi/artikkeli/uutiset/teknologia/uudet_ssd_tallennuslevyt_ovat_petollisia)
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: qwertyy - 21.05.13 - klo:15.49
Itse luin myös kyseisen uutisen ja olen kyllä kutakuinkin täysin erimieltä. Kokemusta plus 5:stä aktiivisessa käytössä jo pitempään olleista SSD:stä ja yhdessäkään ei ole ollut keston suhteen ongelmia. Aivan yhtälailla myös kiitolevyt porsii yleensä odottamattomasti. Toki niiltä saa helpommin jotain varmasti talteen kuin SSD:ltä rikkoutumistilanteessa. Varmuuskopiot tärkeistä tiedostoista pitäisi olla ihan selvä asia jokaiselle tietokoneen omistajalle.

SSD kokemuksieni aikana muuten kaksi kiintolevyä on alkanut osoittaan nopeaa kuolemaa.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Jallu59 - 21.05.13 - klo:16.35
SSD kokemuksieni aikana muuten kaksi kiintolevyä on alkanut osoittaan nopeaa kuolemaa.
SSD:itä vai pyöriviä ?

T:Jallu59
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: qwertyy - 22.05.13 - klo:02.35
Ihan mekaanisia. Tosin kyseessä ei ole mitään tuoreita asemia.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Illu - 22.05.13 - klo:09.29
Kokeilin noita rimpsuja: tmpfs   /tmp       tmpfs   defaults,noatime,mode=1777   0  0 jne.

Eipä mennyt U12.04 violettia ruutua pidemmälle, joten palasin vanhaan. Koneessa on 8 gigaa muistia ja todella harvoin se on kokonaan käytössä (jos koskaan?), joten saatan joskus vielä isommalla innolla tutkia asiaa.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Aatos Rapula - 22.05.13 - klo:10.25
Kokeilin noita rimpsuja: tmpfs   /tmp       tmpfs   defaults,noatime,mode=1777   0  0 jne.

Eipä mennyt U12.04 violettia ruutua pidemmälle, joten palasin vanhaan. Koneessa on 8 gigaa muistia ja todella harvoin se on kokonaan käytössä (jos koskaan?), joten saatan joskus vielä isommalla innolla tutkia asiaa.

Ainakin Debianissa /tmp:it saa rammiin helposti muokkaamalla tiedostoa /etc/default/tmpfs. En tiedä toimiiko Ubuntussa. Sieltä ei tarvitse, kuin poistaa risuaita rivin edestä ja muuttaa "no" muotoon "yes". Lisäksi voi määritellä, että kone rupeaa käyttämään kovalevyä, jos muisti käy vähiin.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Postimies - 22.05.13 - klo:17.22


Ainakin Debianissa /tmp:it saa rammiin helposti muokkaamalla tiedostoa /etc/default/tmpfs. En tiedä toimiiko Ubuntussa. Sieltä ei tarvitse, kuin poistaa risuaita rivin edestä ja muuttaa "no" muotoon "yes". Lisäksi voi määritellä, että kone rupeaa käyttämään kovalevyä, jos muisti käy vähiin.

/tmp kansion siirto rammiin on hyödytön. devtmpfs syrjäyttänee tmpfs ja Gentoossa tmpfs on kielletty fstab-tiedostossa. Täältä voi lukea juttua http://lists.debian.org/debian-devel/2012/06/msg00311.html
Jos vaikka kääntää kernelin on suuri ero make -j4 tai pelkkä make. /tmp kansion siirto tmpfs ei nopeuta. Erikoistapaukset erikkeen. Joku voi kokeilla Rasberryllä kernelin kääntämistä muistikortilla, SSD levyllä ja kenties /tmp kansio rammiin siirrettynä.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: CoReD - 22.05.13 - klo:19.50
Ihan mielenkiintoisia pointteja tuossa viestissä.

Tässähän ketjussa ei nyt haettu tmp @ tmpfs nopeutta esim. kääntämiseen tai muutenkaan, vaan "helpotusta" levykirjoitusten määrässä.

En nyt ihan hirveän tarkkaan tuota ruvennut tavaamaan, mutta tuossa viestissä mainittiin pariin otteeseen, että tmp:lle tapahtuu loppuviimeksi niin vähän levykirjoituksia, että sen siirtäminen tmpfs:ään olisi tältä kantilta turhaa. (tai, ei olisi "ongelmien arvoista") Samalla kuitenkin viestissä pidettiin tmp @ tmpfs ongelmana nimenomaan tmp:n (ja tätä kautta toki keskusmuistinkin) täyttymistä ja tästä seuraavaa swappaamista ja epävakautta. (ja tmp:n rajoitettua kokoa)

Pähkäilen tätä nyt omalta kantiltani:

Minulla on 4gigaa keskusmuistia ja tmpfs tmp voi kasvaa oletusasetuksineen 2gigan suuruiseksi (puolet keskusmuistista).

Tmpfs tyhejenee aina, kun kone käynnistetään uudelleen.

Jos tmp kasvaa yhden käynnissäolojakson aikana yli kahden gigan suuruiseksi täyttäen tmp:lle varatun keskusmuistin ja alkaen swappaamaan (eli siis alkaa aiheuttamaan ongelmia)...niin enkö ole juuri säästänyt yhden käynnissäolojakson aikana 2gigan edestä turhia levykirjoituksia? Onko parin gigan edestä levykirjoituksia sitten asia, minkä välttäminen on turhanpäiväistä?

Edit:

Eipä mennyt U12.04 violettia ruutua pidemmälle, joten palasin vanhaan.

Täytynee katsoa tuo ohje vielä kunnolla läpi, ettei typoja tai mitään ole eksynyt joukkoon. Muistaakseni käytin samoja rivejä 12.04 Xubuntussa, joten pitäisi pelittää Ubuntussakin. Itsellä ei ole samaa ongelmaa ollut, niin ei oikein osaa antaa avuja vianetsintäänkään.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Postimies - 22.05.13 - klo:22.34

Jos tmp kasvaa yhden käynnissäolojakson aikana yli kahden gigan suuruiseksi täyttäen tmp:lle varatun keskusmuistin ja alkaen swappaamaan (eli siis alkaa aiheuttamaan ongelmia)...niin enkö ole juuri säästänyt yhden käynnissäolojakson aikana 2gigan edestä turhia levykirjoituksia? Onko parin gigan edestä levykirjoituksia sitten asia, minkä välttäminen on turhanpäiväistä?

Entäs jos koostat yli 4G DVD levyn tai jotain vastaavaa. Itse luovuin moisesta kikasta. Muistin loppuminen jähmettää koneen. Jos levykirjoitusten määrä huolettaa voi tmp, var ym kansiot siirtää vaikka perinteiselle levylle. Itsellä nyt du -h /tmp näyttää aika pientä kokoa. Mutta jos saan päähäni siirtää 8G HD videon salattuna verkon yli niin /tmp kansio täyttyy... Fiksumpi tapa tehdä joku ram-levy ja ohjata paljon kirjottavat ohjelmat käyttämään sitä. /tmp kansion tyhjennys käynnistyksessä alkaa olla jo oletuksena. Samoin logrotate tyhjentää sitä - yleensä asennettu. Jos joku viallinen ohjelma, niin /tmp täytyy gigatolkulla. Gentoossa uudempi udev vaikuttaa myös. Siinä  tmpfs on kielletty, joten tulevaisuutta ajatellen en suosittele. Kyllä se udev päivittyy Ubuntussakin joskus.

Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: qwertyy - 22.05.13 - klo:23.38
Onko parin gigan edestä levykirjoituksia sitten asia, minkä välttäminen on turhanpäiväistä?
On.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Jaer - 17.12.13 - klo:22.52
http://muropaketti.com (http://muropaketti.com/pcie-vaylalliset-ja-tlc-muistilliset-ssd-asemat-ensi-vuoden-hitti) (<=linkki juttuun) sivulta lainattua:

Lainaus

SSD-asemien yhteydessä yksi yleisimmin esiintyvistä termeistä on SLC, MLC tai TLC.

  TLC-tekniikkaan (Triple-Level Cell) perustuvien NAND-flash-muistipiirien uudelleenkirjoituskyky on huomattavasti huonompi kuin MLC-piireillä (Multi-Level Cell) - noin 1000 kirjoituskertaa verrattuna 3000-5000 kirjoituskertaa.
  SLC-piireillä (Single-Level-Cell) kirjoituskertojen suuntaa antava määrä on peräti 100 000. TLC-piirien valmistus on huomattavasti edullisempaa ja ero MLC-piireihin on arviolta 30 prosenttia ja SLC-piireihin moninkertainen.


Hyvä tietää kun seuraavan kerran menen ostoksille.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Sami Lehtinen - 25.09.14 - klo:18.23
Tässä vähän faktaa siihen, miten levyt kestää. Testattuna Samsung 840 EVO.
http://us.hardware.info/reviews/4178/10/hardwareinfo-tests-lifespan-of-samsung-ssd-840-250gb-tlc-ssd-updated-with-final-conclusion-final-update-20-6-2013  (http://us.hardware.info/reviews/4178/10/hardwareinfo-tests-lifespan-of-samsung-ssd-840-250gb-tlc-ssd-updated-with-final-conclusion-final-update-20-6-2013)

Testin levy on siis TLC levy, eli sitä kaikkein huonoiten kestävää mallia, mitä tällä hetkellä on markkinoilla. Sekin näyttää olevan varsin hyvin kestävää. ;)
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: spark - 25.09.14 - klo:23.14
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?
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Postimies - 29.09.14 - klo:21.56
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.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: raimo - 29.09.14 - klo:23.12

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ää.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Postimies - 30.09.14 - klo:15.42

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.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Tomin - 30.09.14 - klo:16.04
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
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: raimo - 30.09.14 - klo:17.29
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.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Postimies - 30.09.14 - klo:20.51

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ä.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Sami Lehtinen - 03.10.14 - klo:17.20
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.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Postimies - 03.10.14 - klo:18.12
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....
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Sami Lehtinen - 03.10.14 - klo:18.38
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).
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Postimies - 03.10.14 - klo:20.25
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.

Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Sami Lehtinen - 03.10.14 - klo:20.40
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 (http://lwn.net/Articles/468678/) 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.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Hajakenttä - 24.11.14 - klo:18.09
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.



Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: kamara - 24.11.14 - klo:19.01
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ää.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: nm - 24.11.14 - klo:19.15
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ää (http://en.wikipedia.org/wiki/S.M.A.R.T.). 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 (http://en.wikipedia.org/wiki/Trim_%28computing%29) 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ä.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Hajakenttä - 24.11.14 - klo:19.38
Kiitos vastauksista.  ;)
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Hajakenttä - 08.12.14 - klo:15.59
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  8) koska nyt koko muuten ahdas ssd tulee hyvin käytetyksi ja riittää mainiosti.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: raimo - 08.12.14 - klo:16.12
Levyn tarkistuksen voi pakottaa näin:
Koodia: [Valitse]
sudo touch /forcefsckFsck ajetaan seuraavassa bootissa, tiedosto poistuu itsestään.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: nm - 08.12.14 - klo:17.05
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
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Hajakenttä - 08.12.14 - klo:17.17
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ää...
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: nm - 08.12.14 - klo:17.26
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ä?

Levyn viallisia kohtia ei etsitä normaalissa fsck:ssa, vaan se korjaa vain tiedostojärjestelmän rakenteelliset virheet. Levyn vialliset kohdat voidaan kyllä tunnistaa ja kiertää fsck:lla, mutta sitä varten pitäisi ehkä käynnistää kone joltain ulkoiselta levyltä (esim. live-USB-tikulta) ja ajaa sitten fsck manuaalisesti parametrilla -vcck (https://wiki.archlinux.org/index.php/badblocks#Have_File_System_Incorporate_Bad_Sectors):

Koodia: [Valitse]
fsck -vcck /dev/sdb1
Ottaen huomioon levyn iän, tyypin ja SMART-tietojen puuttumisen, tämä tarkistus kannattaisi kyllä tehdä. Tuolla tavalla ajettuna fsck:n pitäisi myös kertoa, kuinka paljon levyltä löytyy viallisia blokkeja.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Hajakenttä - 08.12.14 - klo:18.00
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

Siellä oli "no", muutin sen "yes", talletin ja laitoin päätteeseen vielä:

Koodia: [Valitse]
sudo touch /forcefsck
Sammutin ja käynnistin. Sama virheilmo edelleen. Nyt ehdin jo hiukan enemmän lukea. Siinä on useampi ilmoitus. Ensimmäinen oli /joku/joku/alsa ja perässä muita parikin ilmoitusta. Voivat olla ihan jotain muutakin kuin filesysteemin juttuja.

Edelleen on levyn  tiedoissa sama "Filesystem state: not clean" . Se varmaankin kertoo juuri filesysteemin tilasta, eikä tarkoita levyn solujen "reikiä", joka olisi sitä kulumista. Päättelen tuosta, että filesysteemi ei korjaantunut tuolla. :-\

Lainaus
Levyn viallisia kohtia ei etsitä normaalissa fsck:ssa, vaan se korjaa vain tiedostojärjestelmän rakenteelliset virheet. Levyn vialliset kohdat voidaan kyllä tunnistaa ja kiertää fsck:lla, mutta sitä varten pitäisi ehkä käynnistää kone joltain ulkoiselta levyltä (esim. live-USB-tikulta) ja ajaa sitten fsck manuaalisesti parametrilla -vcck:

Koodia: [Valitse]

fsck -vcck /dev/sdb1


Ottaen huomioon levyn iän, tyypin ja SMART-tietojen puuttumisen, tämä tarkistus kannattaisi kyllä tehdä. Tuolla tavalla ajettuna fsck:n pitäisi myös kertoa, kuinka paljon levyltä löytyy viallisia blokkeja.

Kun tässä nyt on ruvettu ehjää korjaamaan tämän asian hyväksi niin ehkäpä värkkään jonkin tikun ja ajan tuon komennon. fsck -vcck /dev/sdb1? Ehkäpä myös sda1 ja sdb5?

Lainaus
Tuolla tavalla ajettuna fsck:n pitäisi myös kertoa, kuinka paljon levyltä löytyy viallisia blokkeja

Tuo vanhenemisen määrä olisi mielenkiintoista tietää.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: nm - 08.12.14 - klo:18.58
Edelleen on levyn  tiedoissa sama "Filesystem state: not clean" .

Nyt kun googlasin uudelleen, löysin tällaisen maininnan: https://access.redhat.com/solutions/363354

Eli ext2-tiedostojärjestelmässä (tai journaloimattomassa ext3/4:ssä) tuo olisi normaali merkintä silloin kun osio on liitettynä. Journaloidussa ext3:ssa ja ext4:ssä se taas viittaa tiedostojärjestelmän ongelmaan.

Kun tässä nyt on ruvettu ehjää korjaamaan tämän asian hyväksi niin ehkäpä värkkään jonkin tikun ja ajan tuon komennon. fsck -vcck /dev/sdb1? Ehkäpä myös sda1 ja sdb5?

Juu, kannattaa saman tien tarkistaa kaikki osiot.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Hajakenttä - 08.12.14 - klo:22.18
Nämä tämän eeePC:n ssd-muistit kun ovat levyjen mittakaavassa lilliputteja tämä tarkastus sujui aika nopeasti. Suurimmankin osion reilussa tunnissa. Tein ajon tämän Xubuntun omalla asennus-sd-kortilla, joka oli vielä tarjolla juuri tehdyn asennuksen jäljiltä.

Tämä Xubuntu on siis kohtalaisen tuore. Asensin sen uudelleen kun en ollut tyytyväinen 12.04 > 14.04 päivitettyyn jakeluun. Sillä oli paljon jäänteitä entisestä ja sovellukset kaatuilivat. Sillä oli möhötautiakin, eikä meinannut mahtua näille lilliputtilevyille. Kun KeePassX ei meinannut pysyä tolpillaan sain tarpeekseni. Siinä kun on suuri määrä salasanoja, joita tarvitsen ja en niitä mitenkään muista ulkoa. Ne on generaattorilla tehtyjä sikavaikeita ja pitkiä. Onneksi aavistin jotain tällaista ja varmuuskopoita tehdessä otin KeePassX:n näymästä kuvakaappauksen ja tulostin paperille. Nyt on Xubuntu hyvässä iskussa ja levyt minimaalisessa käytössä.  Varmuuskopiotkin ovat tuoreita, joten uskalsin ajaa tämän tarkastuksen. En nimittäin lainkaan uskonut, että levytesti ei tuhoa mitään. Se pelko taitaa juontua 1980-luvun PDP ajalta. Ehjänä kyllä pysyi. Taita tuo vaatimus ajaa tämäkin roottina, vaikka mitään tunnussanaakaan ei ole, johtua siitä, että korostetaan käyttäjälle, että katso tarkkaan mitä teet!

En silti yhtään tiedä mitä nämä tulokset kertovat. Jotta asia olisi jotenkin diagnostinen, ja jotta ssd:n 6 vuoden jokapäiväisen käytön kuluminen saataisiin osoitettua, laitan tuloksen tähän näkyville ja pyydän tulkinta-apua.  :)

Tarkoittaako tuo "random" että levyä ei tarkastettu kokonaan systemaattisesti, vaan jollain satunnaiskuviolla pistokokeina?

sdb1 on / (kernel ja käynnistyslatain)
sdb5 on /home
sda1 on /usr

Koodia: [Valitse]
xubuntu@xubuntu:~$ fsck -vcck /dev/sdb1
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
fsck.ext2: Permission denied while trying to open /dev/sdb1
You must have r/w access to the filesystem or be root
xubuntu@xubuntu:~$ sudo su
root@xubuntu:/home/xubuntu# fsck -vcck /dev/sdb1
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
/dev/sdb1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

       24124 inodes used (15.81%, out of 152608)
        2117 non-contiguous files (8.8%)
          13 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 1947/37/0
      351987 blocks used (57.67%, out of 610351)
           0 bad blocks
           1 large file

       20142 regular files
        2568 directories
          59 character device files
          25 block device files
           0 fifos
           1 link
        1290 symbolic links (1140 fast symbolic links)
          31 sockets
------------
       24116 files
root@xubuntu:/home/xubuntu# fsck -vcck /dev/sdb5
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
/dev/sdb5: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdb5: ***** FILE SYSTEM WAS MODIFIED *****

        6238 inodes used (0.76%, out of 820928)
        2134 non-contiguous files (34.2%)
           5 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 2115/99/0
     1062690 blocks used (32.40%, out of 3280384)
           0 bad blocks
           1 large file

        5787 regular files
         442 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
        6229 files
root@xubuntu:/home/xubuntu# fsck -vcck /dev/sda1
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done                                                 
/dev/sda1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****

      174258 inodes used (70.69%, out of 246512)
        4895 non-contiguous files (2.8%)
         196 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 4809/52/0
      720881 blocks used (73.22%, out of 984576)
           0 bad blocks
           1 large file

      114661 regular files
       16976 directories
           0 character device files
           0 block device files
           0 fifos
          12 links
       42612 symbolic links (37104 fast symbolic links)
           0 sockets
------------
      174261 files
root@xubuntu:/home/xubuntu#
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: qwertyy - 08.12.14 - klo:22.43
Aiheeseen liittyen. Tuli vastaan tämä testi, josta luin tuolloin kun se on käynnistetty ja pääsyt unohtumaan jo ajat sitten. Enpä arvannut että testi on ollut tähän asti päällä.

Modernin SSD:n kuolemista ei kovin kauheasti kannata jännittää :)
http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-petabytes

HTPC:ssäni on Kingstonin aika käpyistä value sarjaa oleva 120Gt SSD. Tuli juuri katsottua sen speksit.
- Controller Writes to NAND = 7870Gb
- Write amplification? = 1,211
- Remaining life = 100%

Tuo asema on hoitanut en tiedä minkämoisen tuntimäärän leffastreameja, mutta sanotaan että paljon. Ajallisesti ollut käytössä äkkiä arvioiden 3 2 vuotta, noin 24/54 päällä. Tietystikin asema on ollut lähes idlenä, mitä nyt tyyliin F@H on pyörinyt koneella, joka ei kovin paljoa tietystikään asemalle kirjoita.

*edit*
Ei tuo ollutkaan niin käpyistä sarjaa mitä ensin muistin. Näyttää olevan V200 sarjalainen. Nykymittapuulla hidas asema.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: spark - 09.12.14 - klo:01.58
Huomasin tuossa mielenkiintoisen ilmiön Kingston V300 120GB SSD asemalla. Fstrim komennolla trimmaantuu ilmoituksen mukaan koko vapaa levytilan alue. Jos fstrimmin tekee heti 5s perästä uudelleen, niin trimmattavaa on jo jotain sata megaa. Joskus minuutin päästä jo gigoja ja kohta koko vapaa alue.

Onkohan tuo ominaisuus vai jotain ongelmia tuon fstrim komennon kanssa? 50GB trimmaamisessa kestääkin useita minuutteja. Kannattaakohan tuossa trimmailut tehdä harvemmin. tapahtuuko siinä turhaa kirjoitusta, kun se "tyhjä" levytila näennäisesti täyttyy hetimmiten?

Muut kaksi eri valmistajien SSD levyä toimii, kuten pitää.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: nm - 09.12.14 - klo:11.40
Taita tuo vaatimus ajaa tämäkin roottina, vaikka mitään tunnussanaakaan ei ole, johtua siitä, että korostetaan käyttäjälle, että katso tarkkaan mitä teet!

Kyllähän fsck vaatii aina pääkäyttäjän oikeudet, koska se käsittelee osioita suoraan raakatasolla ja se on jo tietoturvasyistäkin estetty tavallisilta käyttäjiltä. Ubuntun sudo-systeemillä salasanaksi tietysti kelpaa ylläpito-oikeuksilla varustetun käyttäjän oma kirjautumissalasana.

En silti yhtään tiedä mitä nämä tulokset kertovat. Jotta asia olisi jotenkin diagnostinen, ja jotta ssd:n 6 vuoden jokapäiväisen käytön kuluminen saataisiin osoitettua, laitan tuloksen tähän näkyville ja pyydän tulkinta-apua.  :)

Aika selkeästi tuo toteaa, ettei huonoja blokkeja tai muutakaan vikaa löytynyt. "0 bad blocks".

Tarkoittaako tuo "random" että levyä ei tarkastettu kokonaan systemaattisesti, vaan jollain satunnaiskuviolla pistokokeina?

Tietääkseni random viittaa vain testissä käytettävään satunnaiseen dataan, jolla virheellinen toiminta saadaan paremmin esille. Testi käy kuitenkin koko levyn pinnan läpi.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Mistofelees - 09.12.14 - klo:12.22
Asensin ssd-levyn (Kingston 120Gt) ja samalla Debianin suoraan levylle eli niin että /home oli myös ssd-levylllä. Ja kylläpä kaikki toimi nopeasti, ohjelmat käynnistyivät *heti*. Mahtavaa!

Mutta, sitten siirsin /home:n vanhalle kovalevylle ja nyt sitten tuli harmittava parin sekunnin viive selaimen käynnistymiseen. Tiedän, ei ole paljon mutta kun ehti nähdä sen viiveettömänkin käynnistymisen.

Kysymys siis on: Onko nykyisillä SSD-levyillä enää merkitystä luku/kirjoituskerroilla. Selain kirjoittelee aika paljon ja nyt ne eivät mene SSD-levylle. Mutta onko tällä enää nykyisin merkitystä? Levyllä kuitenkin luvataan viiden vuoden takuu...

/Home ei taida olla se pahin SSD:n kuormittaja. Paljon pahempi on /var/log.
Joissain koneissani olen siirtänyt sen RAM:lla pyörivään tmpfs -järjestelmään.
Lisäksi olen aina minimoinut lokien määrän. On aivan turha tallettaa kuin yksi kerros lokeja, jollei niitä koskaan tule lueskelleeksi.
Swapin olen ottanut kokonaan pois päältä, jos RAM:a on tarpeeksi. Onneksi Linux pärjää hyvin 2GB RAM:lla ja loistavasti 4GB:llä. Vain raskaimpiin projekteihin olen joutunut varaamaan 16GB. Jopa Raspin 512MB toimii hyvin, ellei käytä GUI:ta.
Pelejä ja multimeteliä en ole kokeillut, ei kiinnosta.

Saisiko tuon /var/log:n sellaiseksi, että se tallettuisi levylle vain esim kerran päivässä tai konetta sammuttaessa ?
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: qwertyy - 09.12.14 - klo:18.27
Huomasin tuossa mielenkiintoisen ilmiön Kingston V300 120GB SSD asemalla. Fstrim komennolla trimmaantuu ilmoituksen mukaan koko vapaa levytilan alue. Jos fstrimmin tekee heti 5s perästä uudelleen, niin trimmattavaa on jo jotain sata megaa. Joskus minuutin päästä jo gigoja ja kohta koko vapaa alue.

Onkohan tuo ominaisuus vai jotain ongelmia tuon fstrim komennon kanssa? 50GB trimmaamisessa kestääkin useita minuutteja. Kannattaakohan tuossa trimmailut tehdä harvemmin. tapahtuuko siinä turhaa kirjoitusta, kun se "tyhjä" levytila näennäisesti täyttyy hetimmiten?

Muut kaksi eri valmistajien SSD levyä toimii, kuten pitää.
Ei ole kyllä Linuxien kanssa SSD:stä käytännössä kokemusta, mutta kuulostaa kyllä todella oudolta käyttäytymiseltä. Windowsissa itsellä SSD:t "optimoidaan" noin viikon välein, eli käsitykseni mukaan ajetaan trim-komento läpi ja kyseinen toiminto kestää itsellä maksimissaan noin 20s. Viikon sisään olen katsonut esim. useita tunteja leffasteamia, jonka cache menee SSD:lle ja äsken vilkaisin, että viikko viime optimoinnista ja tila oli edelleen "ei kaipaa optimointia" ja kun aktivoin toiminnin, niin noin 5 sekuntia kesti tällä kertaa.

Muutenkin kuulostaa erittäin oudolta, että tuohon voisi mitenkään mennä minuuttikaupalla aikaa. Eihän tyhjän tilan ylikirjoittaminenkaan kestä SSD:llä, tietysti tapauksesta riippuen, kuin arviolta noin kaksi minuuttia???

*edit*
Vaikka tuo trim on noin lyhyt tapahtuma, niin en ole kuitenkaan törmännyt "jitteriin" kuin kerran ja silloin epähuomiossa kirjoitin aseman ihan ns. piripintaan. Samsungit on siitä miellyttäviä, että niihin on helppo määritellä tuo vapaa tila.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Sami Lehtinen - 11.12.14 - klo:20.22
Minulla on sellainen tuntuma, että SSD-levyt kestävät ainakin sen mitä tavallisetkin levyt.

Toi on erittäin monisyinen ongelma. SSD:t hajoaa siinä missä muukin elektroniikka, tuo "loppuunpalaminen" on yksi niistä ongelmista jotka tuskin tulee normaalissa kotikäytössä koskaan vastaan. Enemmänkin tulee muista puolijohteista tuttuja ongelmia. Kyllä, niiden kanssa oli aikanaan jopa paljon enemmän ongelmia kuin kiintolevyjen. Mutta se tulee taas just siitä, että mikä on sitten se laatu oikeasti. Sitä kun on yleensä todella vaikeaa mitata, muuten kuin siten, että ostat ison kasan laitteita ja katsot muutaman vuoden mitä tapahtuu. Osa laitteista on selvästi huonompia ja esimerkiksi posahtaa järjestelmällisesti kolmessa vuodessa ja osa taas kestää "ikuisesti", ehkä vuosikymmeniäkin ilman mitään ongelmia.

Juttelin itseasiassa juuri eilen eurooppalaisen tukkurin kanssa tuosta asiasta joka on toimittanut hieman suurempia määriä SSD:tä, kuin mitä useimmilla taitaa tulla edes töissä vastaan.

Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: spark - 12.12.14 - klo:01.37
Tuossa vähän tuoreempaa katsausta SSD kestävyyteen. Ei kannata noiden testien perusteella olla kestävyydestä kovin huolissaan  8)

Lainaus
The SSD Endurance Experiment: Two freaking petabytes

MORE THAN A YEAR AGO, we drafted six SSDs for a suicide mission. We were curious about how many writes they could survive before burning out. We also wanted to track how each one's performance characteristics and health statistics changed as the writes accumulated. And, somewhat morbidly, we wanted to watch what happened when the drives finally expired.

Our SSD Endurance Experiment has left four casualties in its wake so far. Representatives from the Corsair Neutron Series GTX, Intel 335 Series, Kingston HyperX 3K, and Samsung 840 Series all perished to satisfy our curiosity. Each one absorbed far more damage than its official endurance specification promised—and far more than the vast majority of users are likely to inflict.

The last victim fell at 1.2PB, which is barely a speck in the rear-view mirror for our remaining subjects. The 840 Pro and a second HyperX 3K have now reached two freaking petabytes of writes. To put that figure into perspective, the SSDs in my main desktop have logged less than two terabytes of writes over the past couple years. At this rate, it'll take me a thousand years to reach that total.

So, yeah. Pretty insane. It's time for another check-up...

http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-petabytes
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: petteriIII - 12.12.14 - klo:07.56
En osaa tavaroitani hoitaa. Esimerkiksi SSD:n kanssa en ole TRIM:miä kokeillutkaan eikä fstab- ja muita virityksiä ole ollenkaan. Enkä viitsikään hoitaa kökkäleitä: jos SSD ei kelpaa semmoisenaan niin sitten käytetään jotain muuta.

Mutta niin kauan kuin SSD:itä on ollut olen niitä käyttänyt. Ensimmäinen SSD:ni kului pehmeäksi viidessä vuodessa - mutta useimmat pyörivät kovalevyt eivät kestä niinkään kauan. Nykyinen SSD:ni on toiminut jo neljä vuotta vaikka dataa kulkee useampi giga päivässä edes-takaisin.

Muuten SSD:ni ovat myöskin säilyneet nopeina - joskus on pakko käyttää pyöriviä kovalevyjä vähän aikaa ja tuskailla niiden hitauden tähden. Kun saa palata SSD:hen on se aina riemukas kokemus. Jotta ihmiset olisivat onnellisia niin sanotaan että ehkä SSD:ni ovat hidastuneet 100%. Perunanko väliä sillä on jos sitä ei käytännössä huomaa ?
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: raimo - 12.12.14 - klo:12.41
En osaa tavaroitani hoitaa. Esimerkiksi SSD:n kanssa en ole TRIM:miä kokeillutkaan eikä fstab- ja muita virityksiä ole ollenkaan. Enkä viitsikään hoitaa kökkäleitä: jos SSD ei kelpaa semmoisenaan niin sitten käytetään jotain muuta.

Kannattaisi kyllä kokeilla, ei ole vaikeaa yhtään:
Koodia: [Valitse]
sudo fstrim -v /
Koodia: [Valitse]
sudo fstrim -v /homejne.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Sami Lehtinen - 12.12.14 - klo:17.49
Discardin käyttäminen (realtime trim) voi hidastaa järjestelmän toimintaa. Toisaalta, riippuen taas levystä, niin sillä trimmaamisellakaan ei ole niin isoa merkitystä. Tässä just kateslin että yli vuoden käytössä ollut SSD ei ole näköjään menettänyt edes 1% vielä sen life-timestään.

Tuli vaan mieleen, että perinteisissäkin levyissä riippuen vähän käyttöympäristöstä tulee helposti käynnistyskerrat tai käyntitunnit täyteen. Tossa yhdessä levyssä mikä mulla on NAS purkissa kiinni on kulunut 25% käynnistyskerroista vuodenaikana. Jossain läppärissä toi voi tulla vielä huimasti nopeammin täyteen.

Toisaalta kuten SSD:n lifetime, niin ei noikaan SMART arvot tarkoita sitä että levy hajoaisi heti siihen paikkaan. Mutta kunhan vaan tällaisia teoreettisia laskureita tässä listailin.
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Ville Pöntinen - 13.12.14 - klo:22.37
Hieman näkökulmaa, vailla faktan faktaa:

Mulla on nyt joitain vuosia ollut pöytäkoneessa ensin yksi ja nyt toinen ssd-levy ubuntun juurena. Vaihdoin vaan kun sain hieman isomman käyttööni.  Home on kokonsa takia perinteisellä kiekolla.

Mua ei oikeestaan kauheesti kiinnosta koska tai miten tuo ssd hajoaa, rahallinen panos on aika pieni siihen verrattuna että kone käynnistyy 10x nopeudella. Enempi pelottaa home-kiekon hajoaminen, vaikka varmuuskopiot meneekin säännöllisesti, olisi sen palauttamisessa enemmän työtä kuin root-ssd:n uudelleenasennuksessa.

Niin kauan kuin ssd on mulla vain ultraläppäreiden tms ainoa levy tai vain juurena, en tosiaan jaksa alkaa säätämään?
Otsikko: Vs: SSd-levyt ja kirjoituskerrat
Kirjoitti: Sami Lehtinen - 16.12.14 - klo:17.52
Yli vuosi ollut 256 giganen SSD käytössä, eikä edes 1% ole lähtenyt vielä endurancesta... Pitääkin olla huolissaan tuosta SSD:n kulumisesta.

Onhan tuo SSD levy toki hyvä investointi kun hankintakustannukset voi jakaa kirjanpidossa sadalle vuodelle. ;)