im erstan Beispiel sieht man die smartctl Ausgabe für eine konventionelle
HD 2.5"
Dabei ist der "Seek_Error_Rate" Wert an Position 7 von Bedeutung um eine
langsam kapputgehende Disk zu idenfifizieren.
Der Wert 082 ist zu wie folgt zu übersetzen:
ein Seek_Error tritt alle 10⁸·² Bytes (Bits, da bin ich mir nicht ganz sicher), die von Disk gelesen werden, auf.
Eine Disk bei der dieser Wert beim Lesen zunimmt deutet auf einen
langsamen aber sicheren Ausfall hin.
1
>date ; smartctl -a /dev/sdb | grep Seek_Error_Rate
Mir stellt sich nun die Frage, welchen Wert ich bei SSDs im Auge
behalten muss, um auf einen Ausfall vorzeitig vorbereitet zu sein.
Wie bei HDDs: die mit „pre-fail“ gekennzeichneten Felder.
Im Übrigen sagt der Raw-Wert ohne interpretation wenig aus, stattdessen ist zu schauen, wie weit das mit „VALUE“ gekennzeichnete Feld von dem mit „TRESH“ entfernt ist. Wenn der momentane Wert unter die Schwelle fällt, kann man mit einem baldigen Ausfall rechnen.
Der Wert 082 ist zu wie folgt zu übersetzen:
ein Seek_Error tritt alle 10⁸·² Bytes (Bits, da bin ich mir nicht ganz
sicher), die von Disk gelesen werden, auf.
Eine Disk bei der dieser Wert beim Lesen zunimmt deutet auf einen
langsamen aber sicheren Ausfall hin.
"Schon heute bedeckt der Sozialismus ein Fünftel unserer Erde! Und schon bald wird es ein Sechstel, ein Siebtel, ein Achtel, ein Neuntel und ein Zehntel sein ..."
Danke für Deine Mühe der Suche.
Ich wollte mich mit Gleichgesinnten
hier im MC Forum austauschen.
Wenn Dir das Thema als zu unspektakulär
erscheint und Dein Interesse nicht trifft
kannst Du es ja überlesen.
Ich freue mich über sachdienliche Antworten
will und kann aber keinen dazu zwingen.
im Übrigen steht zwar im angegebenen PDF von Samsung
was die Parameter in etwa bedeuten
195 ECC Error Rate -> The percentage of ECC correctable errors.
199 CRC Error Count -> The number of Cycle Redundancy Check (CRC) errors. If there is a problem between the host and the SSD, the CRC engine will tally the error and store it in this attribute.
wie sie aber zu interpretieren sind habe ich aber auf die
Schnelle nicht gefunden.
Und das war was ich hier im Forum eigentlich erläutern und
erfahren wollte.
Wenn Dir das Thema als zu unspektakulär
erscheint und Dein Interesse nicht trifft
kannst Du es ja überlesen.
Dein Belehren kannst du für dich behalten. Lern’ lieber ’ne Suchmaschine zu bedienen. Der zweite Treffer bei mir wäre ein Link zum Wiki von Thomas Krenn gewesen, in dem zumindest eines der beiden Felder ausführlich erläutert wird. Ein weiterer, gezielter Suchlauf findet Ähnliches für das zweite gesuchte Feld. Eine ebenfalls sehr empfehlenswerte Literatur wäre die Manpage zu ›smartctl‹, btw. – hilft sehr beim initialen Verständnis, das hier offenbar zu fehlen scheint.
Wie auch immer: die Felder beinhalten geloggte Fehler, aus denen nicht auf den Zustand des Devices mit Bezug auf die verbleibende Lebensdauer geschlossen werden kann („Old_age“).
ich behalte meistens mein Ansichten für mich und habe nicht vor
Dir Belehrungen anzubieten, genauso wie ich auf Belehrungen
Deinerseits gerne verzichte, soweit sie nicht zum Thema gehören.
Ich habe Dir meinen man page Output zu smartctl angehängt und eine
Resultat von grep mit den Schlagwörtern ECC, CRC, ERROR, RATE, COUNT, 194, 199 auf den Text.
Du kannst Deine eigenen Schlüsse daraus ziehen, wenn Du Zeit und Lust
dafür erübrigen kannst - aber nur freiwillig - kein Zwang.
Die Materie zu Unix und Linux unterliegt ständigen Veränderungen und
man muss immer versuchen sein Wissen auf den neusten Stand zu bringen,
wenn auch es nicht immer so einfach ist.
Du kannst mir aber glauben, dass mein Arbeitgeber durchaus mein
Wissen zu der Thematik schätzt und auch teuer vergütet.
Womit sich Deine Annahme
initialen Verständnis, das hier offenbar zu fehlen scheint
nicht zweifelsfrei belegen lässt.
Ich wünsche Dir ein schönes WE und dass Du Dein emotionales
Kostüm etwas toleranter tunest.
Die Materie zu Unix und Linux unterliegt ständigen Veränderungen und
man muss immer versuchen sein Wissen auf den neusten Stand zu bringen,
wenn auch es nicht immer so einfach ist.
Bei dem hier angesprochenen Thema hat sich in den letzten zehn Jahren nicht sehr viel geändert. Auch hat es wenig mit Linux oder gar Unix zu tun, sondern mit SMART. Dass es für dich neu zu sein scheint, widerspricht deiner Darstellung, dass ein initales Verständnis vorliegen würde. Dies ist mein Schluss, den ich aus deinen OT-Rechtfertigungen ziehe.
Du kannst mir aber glauben, dass mein Arbeitgeber durchaus mein
Wissen zu der Thematik schätzt und auch teuer vergütet.
Ah ja – deswegen sollen andere Leute dir die Doku vorlesen? Damit dein Arbeitgeber es dir vergüten kann?
Nochmal: kipp die Namen der Felder in eine Suchmaschine und klicke die Links an. Wenn dann /konkrete/ Fragen oder Verständnisprobleme auftreten sollten, kann da gerne hier weiterschauen – aber dass du von anderen Leuten erwartest, dir die Grundlagen darzulegen, damit du nicht selbst schauen musst, finde ich persönlich ein wenig dreist.
die SSD-Hersteller haben typischerweise ein Attribut als Verschleißanzeige eingerichtet. Die Zellen können ja nur eine bestimmte Anzahl von Schreibzyklen vertragen.
Die c't hatte mal in einem Langzeittest probiert, wie sich die SSDs verschiedener Hersteller denn so verhalten.
Wenn Du die SSDs nach Lebenszeitende nutzt, kannst Du zwei Reaktionen erwarten:
Totalausfall
Verlust der Beschreibfähigkeit bei Aufrechterhaltung der Lesefähigkeit
Dooferweise ist die eingangs genannte Verschleißanzeige herstellerübergreifend leider nicht unter einer bestimmten Attributnummer zu finden.
Bei Crucial habe ich z.B.
202 Percent_Lifetime_Remain
gefunden, bei Adata
169 Remaining_Lifetime_Perc
und bei WD
230 Media_Wearout_Indicator.
Große RAW-Zahlen und große Änderungen bei anderen Attributen in kurzer Zeit sind immer ein Alarmsignal, aber Hersteller wie z.B. Seagate codieren gerne mehrere Informationen in ein Attribut, mit dem Ergebnis, dass große RAW-Zahlen entstehen ohne dass man alarmiert sein müsste.
Sorry meine Formatierung scheint nicht richtig zu funktionieren!
Ich habe sie gerade im Eröffnungsposting korrigiert. Im Hinweistext bei jedem Schreiben eines Postings sind die Code-Tags erklärt.
Da stehen eckige Klammern wie '[' und ']', um den Code einzuleiten. Du benutztest aber stattdessen '<' und '>'. Außerdem ist dort zum Abschluss des Codes der Slash angegeben (das ist der über der 7 auf der Tastatur). Du verwendetest aber den Backslash (neben dem ß).
Danke für Deinen Eingriff und das zurecht Formatieren meines
Postings. Werde mir hoffentlich merken '[]' und nicht '<>'
Bei den Slashes habe ich beide probiert, was aber sinnlos war,
weil die Klammerung ja falsch war.
