Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Laitealue => Aiheen aloitti: SuperOscar - 30.10.07 - klo:22.13
-
Onko asiantuntevia mielipiteitä Slashdotin uutisesta (http://hardware.slashdot.org/article.pl?sid=07/10/30/1742258&from=rss), jonka mukaan Ubuntun käytöllä olisi mahdollisesti ikäviä seurauksia läppärien kiintolevyille? Tosin huomautettakoon heti, että pääsyyllinen ei ole Ubuntu, mutta se ei ainakaan auta ratkaisemaan ongelmaa.
Kävin myös katsomassa tuon jutun kommentissa mainittua wikiä (https://wiki.ubuntu.com/DanielHahler/Bug59695), mutta se on valitettavan keskeneräinen eikä paljon auta. Sikäli kuin osaan jutussa mainitun smartctl-ohjelman tulostetta lukea, läppärini kiintolevyn Load_Cycle_Count-arvo on 200 – mutta mitä sitten? Onko se hirveän huono vai...?
-
Tämäpä onkin mielenkiintoinen kysymys. Mulla on tänä syksynä hajonnut Linux-kannettavista kolme levyä, käytettyinä tulleita tosin. Ongelmiin kyllästyneenä hankin koneisiin upouudet levyt, ja nyt kun katson smartctl:lla, näissä kahdessa läppärin levyssä (molemmat hankittu syyskuussa -07) on tuo load cycle count ensimmäisessä 54901 ja toisessa 45277. Taitavat olla aika isoja arvoja..?
-
Samsungin levy itselläni ja nukkumaan näyttäisi menevän melko usein
225 Load_Cycle_Count 0x0012 051 051 000 Old_age Always - 498034Kuinka pitkältä ajalta mahtaa olla niin tämä ei ainakaan tuo selvennystä: 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 228203Kun ei tämä 26 vuotta ole päällä ollut, ainakaan tietääkseni... Jos tuo olisi vaikka minuutteja niin 90 sekunnin välein parkkeeraisi keskimäärin ja levy olisi ollut 0.43 vuotta päällä (mahdollista kun saattaa olla vajaan vuoden vanha kiintis). Jonkun verran kilkattaa. Vanhan hitachin deathstarin laitoin vaihtoon kun kilinä kävi jo häiritseväksi, vaihto ei sinällään silloin harmittanut kun se vanha levy oli 40 gigaa ja uusi oli 100.
-
Mitä noista rivin arvoista siis oikeasti pitäisi lukea?
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 2163
Noiden numerorivien aluksi annetaan tällainen otsakerivi:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
Tuosta päättelin, että VALUE eli minulla 200 on kiinnostavin, mutta...?
-
Mitä noista rivin arvoista siis oikeasti pitäisi lukea?
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
Käsittääkseni tuo RAW_VALUE on se kiinnostava. Noista muista en ole ikinä saanut selkoa.
-
Samsungin nykyiset 2.5" levyt (kuten tämä oma, malliltaan HM080HC) laskee "käyttötunneiksi" puolikkaita minuutteja. Jako kahdella ja sitten 60:llä antaa tunnit. Tuo raw value on se kiinnostava lukema, pelkkä value on sellainen ihmiselle suuntaa antava arvo, eli esim. lukema on aluksi vaikka 100, ja alkaa sitten levyn kuluessa laskea kohti raja-arvoa (tresh). Sitten kun menee alle, on aika vaihtaa levy tai ainakin varautua ongelmiin. Worst on sitten levyn eliniän aikana sattunut huonoin arvo, josta näkee vaikka lämpötilan tapauksessa kuumimman lämpötilan. Tasaisesti laskevien mittarien kohdalla tuolla arvolla ei liene merkitystä kun worst on aina sama kuin value.
Nyt kun muutin hdparm -B254:llä asetuksia, ei levy pidä enää sellaista lukupään parkkeerausääntä, joka tähän mennessä onkin vähän ihmetyttänyt ja kuulostanut jotenkin huolestuttavalta. Load cycle countin value on 95, varmaan se alun perin on ollut 100. Että kyllä aika äkkiä on tullut alaspäin, kun ajattelee että levy on käytännössä vielä uusi. Ei hyvä.
Levyissä on myös aika monipuolinen sisäinen diagnostiikka. Smartctl:n vipu -t näyttää testivaihtoehdot ja sillä saa myös käynnistettyä valitsemansa, long-testi on ymmärtääkseni kaikkein kattavin, kestää yli tunnin. Tuloksen näkee sitten esim. vivulla -a, aivan listauksen lopusta.
-
Mitäs mieltä olette sitten siitä, pitäisikö tuo ”hdparm -B 254” asettaa jonnekin rc.localiin tms.?
-
Kyllä. Laitan omakohtaisia perusteluja myöhemmin.
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
hdparm -B 254 /dev/sda
exit 0
-
Mitäs mieltä olette sitten siitä, pitäisikö tuo ”hdparm -B 254” asettaa jonnekin rc.localiin tms.?
Kunhan vaan sitten ei tuo haitallinen asetus palaa, jos koneen laittaa nukkumaan tms. Kai paras olisi muuttaa se sieltä, mistä se alunperin asettuu. Vaikka ideaalitapauksessahan tällaista haittaa ei tietysti olisi vakiona päällä ollenkaan. Olettaen että tuolla asetuksella todella on yhteys levyn kestoikään, pitäisi asiasta mun mielestä olla aika paljon isompi haloo kuin mitä tällä hetkellä on.
-
Load_Cycle_Count kasvaa tosiaan hurjaa vauhtia. Toissapäivänä lukema näkyy läppärissäni olleen 2163, tänään 2268! Tuostahan tulee 50/päivä, vaikka kone on ollut käynnissä vain iltapäivät ja illat.
Eilisestä saakka hdparm-komento on ollut rc.localissa, nyt rakensin vielä pienen lokirutiinin, jolla vain tarkkailla Load_Cycle_Countin arvon kasvua.
-
Pitäisikö uuteen kannettavaan ja ubuntu asennukseen muuttaa jotain asetuksia? ???
Mitä asetuksia windows käyttää?
-
Ilmeisesti todellakin PITÄÄ. Oma kannettavani on vasta vajaan kuukauden ikäinen, ja Load_Cycle_Count on kolmannella tuhannella ja kasvoi 50:n päivävauhtia, ennen kuin tein anttimr:n suositteleman muutoksen rc.localiin.
Nyt arvo näkyy kasvavan 2:n päivävauhtia.
-
Mitä tämä Load_Cycle_Count laskee (selvällä Suomen kielellä)?
Ladata_Jakso_Laskuri?!?
-
”Latausjaksojen määrä” olisi suora käännös, mutta tuskin niitä siksi suomeksi pitäisi kutsua.
Täsmäselitystä ei tunnu löytyvän guuglaamalla edes enkelten kielellä; Wikipediakin (http://en.wikipedia.org/wiki/Self-Monitoring,_Analysis,_and_Reporting_Technology) selittää merkitykseksi vain ”total number of load cycles”, mikä ei juuri auta.
-
Tietääkseni lukema kasvaa kahdessa tapauksessa, ensinnäkin aina kun levy pysähtyy ja käynnistyy (esim. virransäästön vuoksi), ja toiseksi kun levy parkkeeraa lukupäät. Tästä oli juttua jossain ulkomaan sivustolla, jota en tähän hätään löytänyt enää. Ainakaan oma levy ei lopettanut pyörimistä, mutta parkkeerasi lukupäitä tiuhaan tahtiin, mikä tuotti ärsyttävän kilahduksen, monesti useita aivan peräkkäin. Tuota tapahtui etenkin silloin kun kone oli vähällä käytöllä. Nyt onneksi ongelmaa ei enää ole uuden asetuksen myötä.
-
Öh...siis jos jotain asetuksia kannattaa/pitää muuttaa niin eikö siitä kannattaisi tehdä ohje!?! ...ja minä ainakin käytän sitä kun saan koneen takuusta...
-
Pieni howto-pikaohje: (laitetaan wikiin tarvittaessa)
1. Sovellukset - Apuohjelmat - Pääte
2. Avataan tekstinkäsittelyohjelmalla tiedosto
sudo gedit /etc/rc.local
3.
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
hdparm -B 254 /dev/sda # LISÄÄ TÄMÄ RIVI TIEDOSTOON
exit 0
4. Tallenna
5. Käynnistä ubuntu uudestaan
-
Onkos kukaan testannut, pysyykö asetus koneen herätessä nukkutilasta? rc.local suoritetaan vain järjestelmää kylmäkäynnistettäessä.
Tuossa aiemmin mainitussa wikissä oli muitakin ratkaisuehdotuksia, jotka tuntuivat muuttelevan milloin mitäkin asetustiedostoa osin juuri siksi, että nukkutilatkin huomioitaisiin.
PS. Jos ja kun tätä ohjetta on tarvis lisätä wikiin eli tehdä siitä pysyvämpi, kannattaisi varmaan selittää myös, mitä tuo kommentoitu huomautus ”In order to enable or disable this script just change the execution bits” tarkoittaa. Oletusarvoisesti *ubuntussa taitaa rc.localilla olla a+x, mutta kannattaa varmistaa.
-
Lisätään nyt tähän vielä, ettei tuo koko operaatio ole mitenkään pakollinen, riskinä on että levyn elinikä lyhenee, jos kärsii tästä ongelmasta, mutta lukupäiden parkkeeraus tuo hiukan lisää turvaa kolahdusten varalta ja virransäästöä pitäisi ainakin laskennallisesti tulla hieman.
Tuo purkkakorjauksena annettu 254 arvo siis ottaa lukupäiden parkkeerauksen miltei kokonaan pois käytöstä, jokaisen kannattaa miettiä onko se omassa käytössä järkevä asetus vai ei.
Itse en ole tuota korjausta ottanut käyttöön ja katsonkin kuinka pitkään samsunki elää ja hengittää oletuksilla, jos ubuntun kehitystiimiltä tulee asiaan korjaus otan sen tietenkin ehdottomasti käyttöön, jos se on järkevä. rc.localiin laitettu komento suoritettaisiin omassa läppärissäni noin kerran kahdessa kuukaudessa ja kone menee nukkumaan kahdesta kolmeen kertaan päivässä, jolloin asetus pyyhkiytyisi pois samantien.
Edit: Jaa tuolla on tuommoinen wiki, testailen nyt tuota laptop-mode kikkaa, kone ainakin hiljeni jonkin verran...
-
Jako kahdella ja sitten 60:llä antaa tunnit.
Ettei vain kertaa?
-
Rupesin katsomaan oman läppärini levyn tilaa, mutta se ei onnistunutkaan. Tulee vaan tälläista:
$ sudo smartctl --all /dev/sda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
Device: ATA FUJITSU MHT2060A Version: 009B
Serial number: NN68T3913YTD
Device type: disk
Local Time is: Fri Nov 9 00:15:42 2007 EET
Device does not support SMART
Error Counter logging not supported
[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
Device does not support Self Test logging
SMART on enabloituna biossissa levylle ja olen melko varma että ennen tuo smartctl on näyttänyt tämänkin koneen levyn tiedot.
Onko feistyssä joku smart palikka muuttunut vai missä lie vika?
-
Oletko kokeillut ”sudo smartctl -s xxx” (xxx = levy)?
-
Oletko kokeillut ”sudo smartctl -s xxx” (xxx = levy)?
$ sudo smartctl -s on /dev/sda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
unable to fetch IEC (SMART) mode page [unsupported field in scsi command]
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
Ja olen koittanut tota -T permissiveäkin, mutta ei tunnu toimivan. Koitin ulkoisella levylläkin, mutta ei sekään toiminut tässä läppärissä (siis toi smart).
Pitää testata buuttia jollain live levyllä ja testata.