* Jan Ritzerfeld wrote on Mon, Dec 19, 2005 at 22:38 +0100:
Am Samstag, 17. Dezember 2005 23:29 schrieb Steffen Dettmer:
[...]
würde ich nicht unbedingt mit einer guten (sondern mit einer billigen) SMART-Implementierung rechnen.
Wenn es nur das wäre, der Drive-Fitness-Test scheint keinen Deut besser zu sein, bzw. sich auf die SMART-Implementierung der Platten zu verlassen. So ein Tool kann man sich unter dann auch gleich sparen, da hat man ja smartmontools. Interessant ist höchstens noch dftview, damit kann man die Logs, welcher der DFT auf eine eingelegte Floppy schreibt aufschlüssen.
Selbst wenn man von "aussen" alle Sektoren liest und schreibt (letzteres geht i.d.R. schon ohne Datenverlust, man kann ja lesen, schreiben, restaurieren), weiss man noch lange nicht, was sich denn die Plattenfirmware nu genau denkt. Würde mich ja mal interessieren, wie gross so ne Plattenfirmware eigentlich ist. Wäre nicht überrascht, wäre es ein komplexes Stück Software (mit den naturgemäss zahlreich vorhandenen Bugs). Gaaaanz früher - ich glaub bei MFM Platten - gabs Tools, die haben jeden Sektor mehrfach gelesen, die Sektor-Prüfdaten (wie auch immer die korrekt heissen) geprüft (die man heute meines Wissens nach überhaupt nicht mehr aus einer Platte rauskriegt). Klar ist, dass moderne IDE Platten sonstwas am Bus vorgaugeln, z.B. es gäbe 255 Köpfe und jeder Track hätte gleichviel Sektoren (obwohl innen ja weniger sind) usw. Irgendwie wirkt daher ein "Test von aussen" etwa so, als ob ich Motorabnutzung "messe", in den ich probiere, ob das Auto noch von Hamburg nach München fahren kann. Kommt es an, weiss ich nicht, ob der Motor kurz vor dem Tot ist, das Öl auf "Minimal" steht und das Auto vielleicht in Berlin in einer Werkstatt war (gut, ein Blick ins Wartungs-("Smart")-Scheckheft sollte einen reallocate-Eintrag haben, FALLS denn das Scheckheft überhaupt gepflegt wird)...
Bei der einen "langsam und gleichmässig sterbenden" Platte, die ich damals hatte (ne IBM irgendwas, aber das hat nix zu sagen; vielleicht ist IBM schlecht, andere aber nicht unbedingt besser!), war nix mit Smart-Problemen... Hatte ich damals auch von anderen gehört, dass das wohl alles mögliche aber nicht zuverlässig ist...
Es gilt schon prinzipiell nur diese Richtung: SMART sagt kaputt -> die Platte ist wohl kaputt
In der Praxis sagt SMART vermutlich meistens gar nichts, weil die Platten gar nicht mehr antworten :) Weiss nicht, vielleicht spielen da auch Gewährleistungsgründe ne Rolle. Hat eine Platte Fehlereinträge etc., könnte ich sie ja tauschen wollen. Überzeugenden Gerüchten zufolge haben Platte eh /immer/ Fehler, weil das eine Staubkorn pro Kubikmeter irgendwo dann doch ein Loch geschlagen hat, diese aber automatisch reallokiert werden, so dass man es nicht sieht. Früher waren Aufkleber mit der "defect block list" drauf, heute ist das in Software versteckt. Aber der gleiche Fakt. Schon alleine, dass man diese im SMART nicht sieht, zeigt ja, dass SMART "lügt". So kann man nicht einschätzen, ob man orginal 5 kaputte Sektoren (gute Platte) oder 50 (schlechte Platte - Zahlen geraten) hatte. Vermutlich eher 50, weil die mit 5 vermutlich ein SCSI Interface bekommen haben, um überhaupt irgendein Argument zu haben, warum Platten mit solchen Kontrollern plötzlich deutlich teuerer sind (und noch teurer, wenn links und rechts ein Spannungspin am Stecker mit dran ist - sicherlich liegt der Preisunterschied nicht am Stecker selbst ;)).
Eine Anekdote aus den letzten Wochen: Lernpartner hat seinen PC umgebaut und eine Platte im Wechselramen mit einem 40-poligen IDE-Kabel angeschlossen. Naja, im Log fanden sich dann natürlich die typischen Platte-liegt-im-Sterben-DMA-Fehlermeldungen. Fehlerlog der Platte sah das ähnlich, aber "UDMA_CRC_Error_Count" war recht hoch,
Da gibt's also mindestens eine SMART-Implementierung, die etwas tut :)
"Reallocated_Sector_Ct" aber 0. Also mal "smartctl -t long ..." drauf losgelassen. Da man gerade schonmal dabei war auch die anderen Platten mit smartmontools betrachtet. Huch, hda hatte vor einigen Monaten(sic!) auch DMA-Fehler! Also auch mal "smartctl -t long /dev/hda" laufen lassen. Und bei dieser Seagate-Platte war der Test ehrlich, unter Angabe des LBA fand man einen Fehler im Selbsttest-Log, "Reallocated_Sector_Ct" stand auf 2.
Wobei man nicht mal genau weiss, was das wirklich heisst. Vielleicht ist der zweite Chunk je von 1 MB grossen Hotfixes voll, nachdem 8 Sets von 255*512 Byte grossen fehlerhaften "Blöcken" an verschiedenen Stellen relokiert wurde. (Alles ausgedacht). Da es für Kunden sicherlich besser aussieht, wenn bei SMART nix kommt, und Firmen ja es für die Kunden immer besser aussehen lassen wollen, liegt der Verdacht nahe (und zeigt meine minimale persönliche Erfahrung), dass bei SMART halt (fast) nix kommt. Ist ne Platte wirklich kaputt, ist's nämlich eh egal.
Sprich, SMART ist genauso nützlich wie jeder andere Test auch.
Oder wie Studien. Da kann man sich über den Sponsor auch aussuchen, was bei rauskommen soll :-)
Wenn der Test erfolgreich ist (d. h. es wurde ein Fehler gefunden), dann weiß man, daß das Testobjekt fehlerhaft ist, ansonsten ist man aber keinen Deut schlauer als vorher.
Ja, Du willst auf die "logische" Limitierung ("Testen kann man nur die Anwesenheit von Fehlern, nicht deren Abwesenheit"), hinaus, die natürlich vollkommen richtig und eh immer da ist - aber ich denke, SMART ist längst nicht so gut/genau/ehrlich.
00 00 3f 00 00 00 b0 10 25.500
muss zugeben, dass mir das überhaupt nichts sagt :-)
Hmm. Bei der Augabe von meinem smartctl ist da noch eine Spalte "Command/Feature_Name".
Gut, mein tool ist sicherlich etwas ältlich ;)
Ich hab einen Log-Eintrag von meinem Versuch den Write-Cache auszuschalten:
(auch so ein Ding, warum geht das nicht absolut immer? Vielleicht geht es ja NIE, aber manche Platten melden den Fehler bloss nicht :))
After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 00 01 00 00 a0 Error: ABRT
<sarkasmus> Ahh! Error ABRT! Alles klar! Bei ABRT ist ja klar, dass der Write Cache nicht abgeschaltet werden konnte, weil der Fehler ABRT auftrat. Schon toll, dass SMART :-) </sarkasmus>
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- b1 c0 00 01 00 00 a0 00 00:00:06.063 DEVICE CONFIGURATION RESTORE ef 03 0c 01 00 00 a0 00 00:00:06.063 SET FEATURES [Set transfer mode]
"Set transfer mode" war vorher? Oder hat es tatsächlich etwas mit Setting cache mode zu tun? Kann ja sein, dass in irgendeinem IDE Standard sowas steht, hab da NULL Ahnung, aber klingt zumindestens nicht wirklich hilfreich. Aber vielleicht kann ja ein Profi an diesen Informationen tatsächlich erkennen, welcher Fehler beim "Write-Cache-Abschalten" auftrat. Ich würde jedenfalls ein Log in der Form von: After command completion occurred, registers were: ER: 04 FEATURE_NOT_AVAILABLE ST: 51 OPTIONAL_IDE_FEATURE_NOT_IMPLEMENTED SC: 00 NON_FATAL_CONTINUE SN: 01 ERROR_SUCCESSFULLY_LOGGED usw. (alles ausgedacht) CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- b1 c0 00 01 00 00 a0 00 00:00:06.063 IDE_EXT_READ_CAPABILITIES ef 03 0c 01 00 00 a0 00 00:00:06.063 IDE_EXT_READ_CAPABILITIES_OK ec 00 03 01 00 00 a0 00 00:00:06.063 IDE_CNF_SET_CACHE_MORE_READ 10 00 00 01 00 00 a0 00 00:00:06.063 FEATURE_NOT_AVAILABLE usw. (alles ausgedacht - wie immer, ihr kennt das von mir :-) )
(...).
"smartctl -l selftest /dev/hda" zeigt dann das Log der Selbsttests an
Hast Du da mehr als einen Eintrag?
Ja, pro Selbsttest einen. Bei meiner kaputten IBM also 6 Stück oder so.
Ich hab auf zwei verschiedenen Platten genau einen Eintrag (wie auch immer der da reingekommen ist), obwohl schon mehrmals smartctl -t etc. gemacht. Vielleicht ist der Eintrag hardcoded, damit (halb-)schlaue monitortools "ihrern" Testversuch immer "sehen" und nicht warnen, dass SMART "komisch" ist :-)
Natürlich alle ohne Fehler. X-)
Muss dann wohl am Kabel liegen :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.