Aussagekraft von GSmartControl

03/04/2012 - 20:18 von Burkhard Müller | Report spam
Moinmoin!

Ich mach mir momentan Gedanken darüber, wie ernst man die Warnungen von
GSmartcontrol nehmen sollte.
Letztes Jahr bin ich mit meiner Haupt-Linuxinstallation in meinem Desktop-PC
auf eine andere Platte umgezogen, weil GSmartcontrol für die alte Platte
unter ca. 4-5 SMART-Attributen horrend schlechte Werte anzeigte; nebst
dem Kommentar "pre-failure".
Die neue Platte ist seitdem eine SSD, ich habe sie heute mal mit GSmartControl
geprüft - und wieder habe ich bei drei Werten den Kommentar "pre-failure".
Beide Platten funktionieren allerdings weiterhin tadellos.

Da ich schon dabei war, habe ich GSmartControl eben mal auf meinem Notebook
mit zwei Monate alter SSD gestartet: wieder drei mal "pre-failure", allerdings
bei anderen Attributen.

Kann es sein, daß GSmartControl ein wenig Panikmache betreibt - oder sollte
ich mir ernsthaft Sorgen um meinen Rechnerpool machen?
(Ich hab' hier noch zwei weitere Notebooks, aber deren Platten noch nicht
geprüft. Das hole ich vielleicht mal nach, wenn ich Langeweile habe..)

Tschüß, BM
 

Lesen sie die antworten

#1 Sven Hartge
03/04/2012 - 20:59 | Warnen spam
Burkhard Müller wrote:

Ich mach mir momentan Gedanken darüber, wie ernst man die Warnungen
von GSmartcontrol nehmen sollte. Letztes Jahr bin ich mit meiner
Haupt-Linuxinstallation in meinem Desktop-PC auf eine andere Platte
umgezogen, weil GSmartcontrol für die alte Platte unter ca. 4-5
SMART-Attributen horrend schlechte Werte anzeigte; nebst dem Kommentar
"pre-failure". Die neue Platte ist seitdem eine SSD, ich habe sie
heute mal mit GSmartControl geprüft - und wieder habe ich bei drei
Werten den Kommentar "pre-failure". Beide Platten funktionieren
allerdings weiterhin tadellos.

Da ich schon dabei war, habe ich GSmartControl eben mal auf meinem
Notebook mit zwei Monate alter SSD gestartet: wieder drei mal
"pre-failure", allerdings bei anderen Attributen.



Kann es sein, dass du die Ausgabe schlicht falsch verstehst?

Beispiel einer sehr alten Platte von mir:

START OF INFORMATION SECTION ==Model Family: SAMSUNG SpinPoint V80
Device Model: SAMSUNG SV0802N

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 082 075 000 Pre-fail Always - 3584
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 192
5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 253 253 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0024 087 085 000 Old_age Offline - 10979
9 Power_On_Half_Minutes 0x0032 090 090 000 Old_age Always - 54344h+16m
10 Spin_Retry_Count 0x0013 253 253 049 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 104
194 Temperature_Celsius 0x0022 151 106 000 Old_age Always - 29
195 Hardware_ECC_Recovered 0x000a 100 100 000 Old_age Always - 59614447
196 Reallocated_Event_Count 0x0012 253 253 000 Old_age Always - 0
197 Current_Pending_Sector 0x0033 253 253 010 Pre-fail Always - 0
198 Offline_Uncorrectable 0x0031 253 253 010 Pre-fail Offline - 0
199 UDMA_CRC_Error_Count 0x000b 100 100 051 Pre-fail Always - 0
200 Multi_Zone_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0
201 Soft_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0

Wichtig sind NUR die Werte bei "VALUE", bei "WORST" und bei "THRESH".

Die rohen Werte am Ende sind in vielen Fàllen ohne Aussage. Nicht in allen, aber in vielen.

Wie man sieht, geht es der Platte sehr gut, obwohl Sie schon über 6
Jahre alt ist. In dieser Zeit war sie im Dauerbetrieb (sieht man am
Power_Cycle_Count), obwohl es nur eine Desktop-Platte ist.

Die Seek_Time_Performance hat mit der Zeit ein wenig gelitten, der
normalisierte Wert war mal bei 95.

Der TYPE gibt nur an, was für ein Event ausgelöst wird, wenn der
THRESHold (also der Schwellwert) erreicht ist.

UPDATED sagt aus, wann das Attribut veràndert wird, immer live (Always)
oder nur bei einem Offline-Scan (smartctl -t offline /dev/devicename).

Und interessant ist die Spalte WHEN_FAILED.

Dort steht eine Zeit (berechnet hier aus Power_On_Half_Minutes), wann
das Event aufgetreten ist.

Auch das Self-test log kann spannend sein:

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 54337 -
# 2 Short offline Completed without error 00% 54315 -
# 3 Short offline Completed without error 00% 54292 -
# 4 Extended offline Completed without error 00% 54276 -
# 5 Short offline Completed without error 00% 54270 -
# 6 Short offline Completed without error 00% 54248 -
# 7 Short offline Completed without error 00% 54225 -
# 8 Short offline Completed without error 00% 54203 -
# 9 Short offline Completed without error 00% 54181 -
#10 Short offline Completed without error 00% 54158 -
#11 Short offline Completed without error 00% 54136 -
#12 Extended offline Completed without error 00% 54120 -
#13 Short offline Completed without error 00% 54115 -
#14 Short offline Completed without error 00% 54092 -
#15 Short offline Completed without error 00% 54070 -
#16 Short offline Completed without error 00% 54047 -
#17 Short offline Completed without error 00% 54025 -
#18 Short offline Completed without error 00% 54003 -
#19 Short offline Completed without error 00% 53980 -
#20 Extended offline Completed without error 00% 53964 -
#21 Short offline Completed without error 00% 53958 -

Wie wieder sieht: Bisher keine Fehler zur Lebenszeit der Platte (das
wàre im SMART Error Log verzeichnet) und die letzten 21 Selbsttests sind
a) komplett durchgelaufen (Remaining ist 0%) und es gab keine Fehler.
Dies wàre in der letzten Spalte vermerkt.

Nun zu dir: Kann es sein, dass du die Spalte "TYPE" misinterpretierst?
Zeige doch einmal dein _vollstàndiges_ "smartctl -a /dev/devicename".
Bitte dabei auf den Umbruch achten, sonst wird die Sache sehr schwer
lesbar.



Sigmentation fault. Core dumped.

Ähnliche fragen