SSd-levyt ja kirjoituskerrat

[nm]

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:

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.

[Hajakenttä]

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.

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?

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

Tuo vanhenemisen määrä olisi mielenkiintoista tietää.

[nm]

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.

[Hajakenttä]

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#

[qwertyy]

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.

[spark]

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ää.

[nm]

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.

[Mistofelees]

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 ?

[qwertyy]

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.

[Sami Lehtinen]

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.

[spark]

Tuossa vähän tuoreempaa katsausta SSD kestävyyteen. Ei kannata noiden testien perusteella olla kestävyydestä kovin huolissaan 

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

[petteriIII]

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 ?

[raimo]

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.

[Sami Lehtinen]

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.

[Ville Pöntinen]

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?

[Sami Lehtinen]

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.