|
Anzeige
|
Ist die Festplatte gesund?
Gast
#5998201
Hallo ich habe rausgefunden, wie ich die Gesundheitswerte meiner Festplatte unter Linux auslesen kann. Ich weiss nur nicht was die Werte bedeuten. Ist meine Festplatte gesund?
Danke für eure Hilfe! Die Raw_Read_Error_Rate ist nicht gerade klein, aber ich habe hier auch eine Platte, die ähnlich hohe Werte hat. Andere wiederum zeigen dort immer 0 an. Scheint nicht so ganz einheitlich zu sein, was die Hersteller hier als "raw" interpretieren und ausgeben: manch einer gibt offenbar wirklich alles an, was zwar intern fehlerhaft war aber nach außen korrigiert (die "ECC recovered" ist ja genauso hoch), andere wollen sich da nicht so in die Karten gucken lassen und scheinen dort nur zu berichten, ob es permanente Fehler gab. @Gärtner So sieht z.B. eine gesunde Disk aus. === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 136 136 054 Pre-fail Offline - 108 3 Spin_Up_Time 0x0007 100 100 024 Pre-fail Always - 0 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 135 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 140 140 020 Pre-fail Offline - 15 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 911 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 135 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 135 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 135 194 Temperature_Celsius 0x0002 136 136 000 Old_age Always - 44 (Min/Max 19/49) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0 Bei Dir häufen sich Read und Seek errors, wobei ich Dir nicht sagen kann ob das bereits kritisch ist, aber Du näherst Dich dem THRESH Limit. Markus PS.: Mir ist immer noch schleierhaft, warum im oberen thred die selbe Tabelle ordentlich angezeigt wird und bei mir wieder umbrochen ist. Hat jemand da eine Ahnung?
Angehängte Dateien:
Ich schaue meist auf "Reallocated_Sector_Ct" und "Current_Pending_Sector". Wenn die hochlaufen, steigt die Wahrscheinlichkeit eines Ausfalls rapide an. Und die "G-Sense_Error_Rate" ist ziemlich hoch bei Dir ? Ist wohl ein Labtop :-) Vielleicht etwas sanfter mit dem Teil umgehen... Markus W. schrieb: > Bei Dir häufen sich Read und Seek errors, wobei ich Dir nicht sagen kann > ob das bereits kritisch ist, aber Du näherst Dich dem THRESH Limit. Wie gesagt, ich habe hier auch solche (wie du) und solche (wie der TE). Es scheint einfach, dass die Hersteller diese Angaben massiv unterschiedlich berichten. Die, die sich wie die des TE verhält, ist eine:
Die, die schön überall 0 zurück geben, sind von Western Digital und Toshiba. > PS.: Mir ist immer noch schleierhaft, warum im oberen thred die selbe > Tabelle ordentlich angezeigt wird und bei mir wieder umbrochen ist. > Hat jemand da eine Ahnung? Er hat [pre]-Tags benutzt. Daniel B. schrieb: > Ich schaue meist auf "Reallocated_Sector_Ct" und > "Current_Pending_Sector". Die sind übrigens hier 0, auch bei der mit den vielen raw read errors.
Gast
#5998238
Daniel B. schrieb: > Und die "G-Sense_Error_Rate" ist ziemlich hoch bei Dir ? Ist wohl ein > Labtop :-) Vielleicht etwas sanfter mit dem Teil umgehen... Nein. Stand die ganze Zeit im Keller. Im letzten Winter sind Mäuse in den Tower eingezogen. Die haben ziemlich viel Dreck hinterlassen und ich hab mich entschieden das System nicht mehr weiter zu verwenden. Allerdings ist die Festplatte relativ neu und ich hatte gehofft ich könnte die weiter verwenden. Eventuell haben die Mäuse den G-Sensor getriggert? :-) Jörg W. schrieb: > Die, die sich wie die des TE verhält, ist eine: > Model Family: Seagate Barracuda 7200.14 (AF) > Device Model: ST500DM002-1BD142 Es ist eine Seagate IronWolf NAS 8TB ST8000VN0022
Beitrag #5998240 wurde von einem Moderator gelöscht.
Gärtner schrieb: > Es ist eine Seagate IronWolf NAS 8TB ST8000VN0022 Dann ist es wohl so, dass Seagate hier ehrlicher ist als WD und Toshiba. Habe leider nicht mehr so viele andere rotierende Teile herumliegen, gegen die ich testen kann. In vielen Kisten steckt inzwischen eine SSD drin. @Jörg W.
> Er hat '[ pre ]'-Tags benutzt.
Danke für den Hinweis!
Markus
Markus W. schrieb: > 1 Raw_Read_Error_Rate 0x000f 077 064 044 Pre-fail Always > - 51973470 Auch Seagate? ;-)
Gast
#5998274
Jörg W. schrieb: > Markus W. schrieb: >> 1 Raw_Read_Error_Rate 0x000f 077 064 044 Pre-fail Always >> - 51973470 > > Auch Seagate? ;-) Nein. Das sind ja wieder meine Werte. @Markus W.: Beim dritten mal klappts bestimmt ;-) Gärtner schrieb: > Das sind ja wieder meine Werte. pling - plang - plong. Der Papiergroschen ist gefallen. :-)) @Jörg W. und Gärtner, war nur ne Übung für die "PRE-Tags" im Zusammenhang mit Tabellen. Nicht verwirren lassen ;-) Markus
Gast
#5998285
Jörg W. schrieb: > Dann ist es wohl so, dass Seagate hier ehrlicher ist als WD und Toshiba. Genau so ist es. Alle halbwegs aktuellen Platten lesen (besser: raten) einen Wust von Daten und rekonstruieren die gewünschten Nutzdaten durch mehrere Schichten Fehlerkorrektur. Dabei kommt es auf der Mechanikseite immer zu erheblichen Fehlern. Manche Plattenhersteller sind da ehrlich, bei anderen geht der Zähler nur hoch, wenn Daten nichtmehr rekonstruiert werden konnten. Es zählt jedoch nur, was jedoch am Interface ankommt. Daniel B. schrieb: > "G-Sense_Error_Rate" ist ziemlich hoch Das finde ich allerdings auch bedenklich. Vielleicht waren es wirklich die Mäuse, muss man beobachten. Gärtner schrieb: > 188 Command_Timeout 3 > 199 UDMA_CRC_Error_Count 14 Anderes Kabel einsetzen! Jupp schrieb: >> "G-Sense_Error_Rate" ist ziemlich hoch > > Das finde ich allerdings auch bedenklich. Vielleicht waren es wirklich > die Mäuse, muss man beobachten. Ob die Festplatte wohl gelaufen ist, als sich die Mäuse daran zu schaffen gemacht haben? Wenn nicht, wie sollte die Platte dann in diesem Zustand hätte irgendwelche Fehler registrieren sollen?
Gast
#5998309
Jörg W. schrieb: > Ob die Festplatte wohl gelaufen ist, als sich die Mäuse daran zu > schaffen gemacht haben? Wenn es die Mäuse waren, muss sie gelaufen sein. Zwei - drei Mäuse können einen Rechner schon arg zum Wackeln bringen, zumal der Rechner ja irgendwie offen gewesen sein muss. Durch typische Lüftungsgitter kommen mir bekannte Mäuse jedenfalls nicht durch ;)
Gast
#5998312
Jörg W. schrieb: > Ob die Festplatte wohl gelaufen ist, als sich die Mäuse daran zu > schaffen gemacht haben? Die Festplatte lief. Ich habe eine Blende eines PCI-Slots nicht montiert, da ich dachte dies sei nicht notwendig. Die Tiere sind da rein und über die Grafikkarte weiter. Das Nest war auf der Systemplatte (ich versuche erst gar nicht diese wieder zum laufen zu bringen). Gemütliche 30 Grad? Mit der Zeit häuften sich die Fehlermeldungen in dmesg und ich hab mal das Gehäuse geöffnet. Naja, man lernt nie aus ... :-))
Heftige Geschichte. Hätte nicht gedacht, dass die sich da neben lärmende Festplatten und rotierende Lüfter einnisten.
Gast
#5998321
Gärtner schrieb: > Das Nest war auf der Systemplatte Bilder, wir wollen Bilder ;) Also, wenn der Zähler für G-Sense_Error_Rate in mausfreier Umgebung nicht weiter steigt und das Kabel ersetzt ist, spricht nichts gegen einen weiteren Einsatz der Platte. Bei 37 Starts und 6565 Stunden Laufzeit ist die ja gerade mal warmgelaufen.
Gast
#5998336
Jupp schrieb: > Bei 37 Starts und 6565 Stunden > Laufzeit ist die ja gerade mal warmgelaufen. Sehe ich eben so. Und der TO braucht selbstredend eine Katze. Ach da gab es doch einst einen Spruch: Ist die Katze gesund ... Ich sage: "Ist die Festplatte gesund", freut sich der Mensch.
Gast
#5998348
Was -A ausgibt ist uninteressant. Lass mal die extended errorlogs raus, da steht meist sinnvolleres drinn und man sieht genau wo die Platte Probleme hatte, was in den Registern von -A noch gar nicht erfasst wird. Seagate hat bei den SMR-Platten ständig wachsende ECC-Werte, ist aber normal. Jörg W. schrieb: > Die Raw_Read_Error_Rate ist nicht gerade klein, aber ich habe hier auch > eine Platte, die ähnlich hohe Werte hat. Andere wiederum zeigen dort > immer 0 an. > > Scheint nicht so ganz einheitlich zu sein, was die Hersteller hier als > "raw" interpretieren und ausgeben: manch einer gibt offenbar wirklich > alles an, was zwar intern fehlerhaft war aber nach außen korrigiert (die > "ECC recovered" ist ja genauso hoch), andere wollen sich da nicht so in > die Karten gucken lassen und scheinen dort nur zu berichten, ob es > permanente Fehler gab. Laut http://www.users.on.net/~fzabkar/HDD/Seagate_SER_RRER_HEC.html ist bei Seagate u.a. die Seek Error Rate mit 2 Werten gefüllt, "Seek Error Rate The raw value of each SMART attribute occupies 48 bits. Seagate's Seek Error Rate attribute consists of two parts -- a 16-bit count of seek errors in the uppermost 4 nibbles, and a 32-bit count of seeks in the lowermost 8 nibbles. In order to see these data, we will need a SMART utility that reports all 48 bits, preferably in hexadecimal. Two such utilities are HD Sentinel and HDDScan. ... Raw Read Error Rate and Hardware ECC Recovered The raw values of the RRER and HER attributes represent a sector count, not an error count. " Deshalb lohnt es sich, die Rohwerte im Hex-Format anzeigen zu lassen. Solange die oberen 16 bit Null sind, ist alles o.k. Gorgonzola schrieb: > Ist die Katze gesund ... > > Ich sage: "Ist die Festplatte gesund", freut sich der Mensch. ...und findet sie Gorgonzola, freut sich die Maus.
Beitrag #5998370 wurde von einem Moderator gelöscht.
Gärtner schrieb: > Ich weiss nur nicht was die Werte bedeuten Du kannst nicht die Werte der Spalten VALUE WORST vergleichen? (Vielleicht wird das ja nicht gelöscht - der Moderator kann es offensichtlich) Obwohl es eine Laptop-Festplatte ist sind die Werte bei meiner noch sehr gut. Wichtig ist die Zahl von: "Reallocated_Sector_Ct" und eigentlich auch von "Uncorrectable", aber der Wert ist ja Offline. Lesefehler werden wohl eher am Kabel liegen als am Lese/Schreib-Kopf.
Beitrag #5998409 wurde von einem Moderator gelöscht.
Ist eindeutig ein Fall von "fehlenden Maustreiber". > > Die Festplatte lief. Ich habe eine Blende eines PCI-Slots nicht > montiert, da ich dachte dies sei nicht notwendig. Die Tiere sind da rein > und über die Grafikkarte weiter. Das Nest war auf der Systemplatte Ich hätte das auch nie gedacht, wenn es dir nicht passiert wäre. Ein PCI Slotblech ist ja nicht gerade groß. Joerg F. schrieb: > Ein PCI Slotblech ist ja nicht gerade groß. Mäuse (also solche, die eigentlich nicht für Computer gedacht sind :) offenbar auch nicht … Ratten sind da 'ne andere Nummer.
Gast
#5999054
Die Viecher können sich extrem dünn machen. Gefühlt quetschen die auch ihren Kopf zusammen. Ein slotblech ist gar kein Problem. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
