Hohe Schreibleistung in kurzer Zeit normal ? PCIe-SSD

[xxMuahdibxx]

Auslagerungsdatei ... könnte es sein ...

 

[PapaWo]

die pagefile.sys ist schon auf C: Aber bei 12 GB RAM dürfte doch der Zugriff nicht so exzessiv sein, oder ?
Hatte ich bei meiner alten SSD auch so und nie so schnelle Schreibabnutzung.

 

[xxMuahdibxx]

alles vermutungen ... da wir nicht wissen was du alles gleichzeitig machst ... wissen wir auch nicht wie toll Windows auslagert.

 

[Chuuei]

Die Angaben vom Crystal Disk Info kannst du in die Tonne kloppen. Problem ist das SMART nicht standardisiert ist, nicht in welchen Attribut welche Daten stehen, ja noch nicht mal der Attributaufbau ist standardisiert und obwohl einige Attribute quasi identisch genutzt werden von den Herstellern, sind die meisten es nicht. Und das CDI hier Mist baut sieht man im Vergleich mit den OCZ Tool, welches man ja hier als Referenz nehmen sollte da es vom Hersteller ist. Im ersten Screenshot zeigt CDI z.B. eine Anzahl Host Schreibvorgänge von 10448 GB - die Zahl ist falsch. Angezeigt wird da von CDI das Attribut F1 bzw. 241 was einen Rohwert von 28D0 im CDI Screenshot hat, was eben diesen angezeigten 10448 entspricht. Aber die Einheit ist falsch wie der Screenshot vom OCZ Tool zeigt. Es sind nämlich nicht 10448 GB sondern 10448 * 32 MiB was ungefähr 350GB sind. Im OCZ Tool Screenshot hat man zwischen den beiden Teilen eine Differenz im Attribut 241 von 2700 was ca. 90 GB geschriebenen Daten entspricht zwischen den beiden Screenshotteilen. Wie man sieht baut CDI hier richtig Mist mit den Angaben zu den geschriebenen Daten - kann es was dafür? Nee, das liegt einfach daran das SMART kein Standard ist und jeder Hersteller die Attribute benutzt wie er möchte und oft auch nicht öffentlich macht wie man diese genau zu interpretieren hat. Und wo CDI die Daten vom Diagramm her nimmt ist mir komplett schleierhaft. Eventuell noch weitere Logpages in SMART aber um die zu interpretieren brauch man echt die Hilfe der Hersteller idR. Ich lass als Beispiel mal nen Diagramm einer SSD die ich bei mir drin hab da - wie man sieht ist das kompletter Müll was CDI da anzeigt, mit einer niedriger werdenden Anzahl an Lesevorgängen über die Zeit

CDI weiß einfach nicht wie man für manche Hersteller die Attribute zu interpretieren hat. Während sich CDI hier komplett aus dem Fenster lehnt mit den Bezeichnungen der SMART Attribute sind da die SmartMonTools viel zurückhaltender, zeigen ne Handvoll Standardattribute an (aber auch nicht komplett richtig) und bei den meisten nur Unknown Attribute weil es einfach nicht weiß, wie es diese zu interpretieren hat.

 

[PapaWo]

Das ist wirklich interessant und klingt sehr Einleuchtend. Das mit den 32MiB-Werten hatte ich gar nicht bemerkt. Dann wäre ja der Schreck unbegründet. Vielen herzlichen Dank !
Magst du mir auch noch etwas zu diesen "Raw Read Error Rate"-Werten sagen. Oft sind die nach einigen Stunden wieder auf Null. Was bedeutet das ?

Ergänzung (27. Mai 2019)

Oh. Wenn ich mit dem Mouse-Zeiger drüber fahre, erscheint noch eine Erklärung. Diese verwirrt mich noch mehr:

 

[Chuuei]

Hehe, ist doch fein Wieder schönes Beispiel das SMART Daten reine Interpretationssache sind. Die 0 sind die Fehler - keine, alles bestens Und die 11 Millionen sind die gelesenen Sektoren, wobei nen Sektor in der Regel 512 Byte sind, also sind die 11 Millionen da knapp 5,8 GB.

Und wenn du meinst das ist auch manchmal wieder 0, dann wird das wahrscheinlich mit einem Powercycle zurückgesetzt (also PC aus/an).

Rohdaten zu interpretieren kann müßig sein, da man wie gesagt wissen muss, wie der Hersteller das genau meint mit dem Wert, gut das OCZ hier entsprechende Hinweise macht. Mit CDI würde man schon wieder denken die SSD verabschiedet sich bald für immer wenn man nur den Rohwert anguckt. Für die meisten Fälle ist es besser die normalisierten Werte sich anzuschauen, also in der ersten Spalte mit Aktueller Wert und dann die Dritte mit Grenzwert. Wenn der Hersteller sich an das Grundverständnis von SMART gehalten hat, und solange der Grenzwert nicht gerissen wird, ist alles fein und man muss im Prinzip nichtmal genau wissen, was hinter dem Wert steckt. Das ist auch der Grund, warum Tools wie CDI, trotzt alles Schwächen beim interpretieren der Daten für verschiedene Hersteller, doch eine Aussagekraft haben.

 

[PapaWo]

Nochmals herzlichen Dank. Ich denke, heute Nacht kann ich wieder schlafen .

Toll, dass es dieses Forum gibt, und Leute die sich die Zeit nehmen anderen Usern zu helfen 👍

 

[Holt]

Wobei ich halt nicht weiß, was das für Daten sind die da geschrieben werden.

Die Dateien sind doch angegeben auf die so viel geschrieben wird, google halt mal was die für eine Bedeutung haben, es scheint ja ein Cache des Antimalware Tools zu sein.

Die Angaben vom Crystal Disk Info kannst du in die Tonne kloppen. Problem ist das SMART nicht standardisiert ist, nicht in welchen Attribut welche Daten stehen, ja noch nicht mal der Attributaufbau ist standardisiert und obwohl einige Attribute quasi identisch genutzt werden von den Herstellern, sind die meisten es nicht.

Wobei es die Aufgabe des Hersteller der HDD/SSD ist, dies öffentlich zugänglich zu dokumentieren, dann können die Team welche Tools wie CrystalDiskInfo programmieren, die Unterstützung dafür auch einpflegen und sei es nur die korrekten Namen der Attrbute.

CDI weiß einfach nicht wie man für manche Hersteller die Attribute zu interpretieren hat.

Wenn es eben nicht öffentlich dokumentiert ist oder niemand ein Interesse hat es einzupflegen, dann weiß ein Tool dies nicht, wobei CDI OpenSource ist, der Hersteller der SSD da also auch selbst mithelfen kann.

Und das CDI hier Mist baut sieht man im Vergleich mit den OCZ Tool, welches man ja hier als Referenz nehmen sollte

Das Problem der Revos ist, dass es keine nativen PCIe SSDs sind wie sie heute verbreitet sind, sondern ein RAID aus SATA SSD und da liegt es am RAID Controller wie er mit den Anfragen zum Auslesen der S.M.A.R.T. Werte umgeht. Bei den meisten HW-RAID Controllern kann man die S.M.A.R.T. der einzelnen Laufwerke nur über des eigene Tool des Herstellers auslesen, hier scheint es mir ab so zu sein, dass der RAID Controller CDI einfach immer wieder die Werte eines Laufwerks präsentiert und daher Werte plötzlich wieder geringe sind, die eigentlich nur steigen sollten.

Wieder schönes Beispiel das SMART Daten reine Interpretationssache sind.

Ja, daher ist der Blick auf die Werte ja auch wichtiger als die Beurteilung die ein Tool daraus generiert, man muss dann aber eben selbst wissen, wie die Werte bei dem konkreten Modell korrekt zu interpretieren sind. Im Zweifel nimmt man besser das Tool des Herstellers der SSD, dort sollte die Interpretation besser als bei einem 3rd Party Tool sein. Generell ist es aber so, dass die Tools entweder übersensible sind und meinen es gäbe Probleme wo keine sind oder zu entspannt sind und tatsächlich vorhandene Probleme nicht anzeigen. Gerade bei dieser SSD bei der Aktuelle Wert bei vielen Attributen 0 ist und damit dem Grenzwert entspricht, werden viele Tools Alarm schlagen und dies ist auch nicht falsch, denn es gibt sehr wohl Konventionen für die S.M.A.R.T. Werte:
1.) Der Rohwert enthält die konkreten Werte wie z.B. die Zählerstände, ggf. auch mehrerer Zähler und unterschiedlichen Bytes/Words/DWords
2.) Der Aktuelle Wert ist die Interpretation des Controller des Rohwertes und ggf. anderer Faktoren wie der Zeit in der dessen Änderungen erfolgt sind und geht von einem Ausgangswert (meist 100, 200 oder auch 253) runter, je schlechter der Controller das Attribut bewertet.
3.) Der Schlechteste Wert ist der tiefste Stand den der Aktuelle Wert jemals hatte.
4.) Der Grenzwert bezieht sich auf den Aktuellen bzw. den Schlechtesten Wert und beide sollten den Grenzwert nie erreichen oder gar unterschreiten.
Leider halten sich gerade bei den SSDs viele FW Entwickler nicht an diese Vorgaben und machen eben genau so einen Blödsinn wie er auch bei dieser zu sehen ist, nämlich ab Werk den Aktuellen Wert schon auf 0 zu setzen und damit ist die streng genommen ihren S.M.A.R.T. Werten nach, schon ab Werk in einem schlechten Zustand. Die Tools müssen solche Ausnahmen eben kennen und die entsprechenden Attribute eben ignorieren oder werden eben auch anzeigen, dass der Zustand schlecht, was er den Werte nach ja auch ist. Die Schuld liegt aber eben nicht bei den Entwicklern der Tools, sondern denen der FW die die Konventionen der S.M.A.R.T. Werte verletzt haben.

 

[Chuuei]

Da du schon so schön zitierst, solltest du vielleicht auch die Stelle mitnehmen, in der man sieht das wir einer Meinung sind und ich nie was anderes behauptet habe wie du Ich gebe CDI nicht die Schuld für die Fehlinterpretation.

Wie man sieht baut CDI hier richtig Mist mit den Angaben zu den geschriebenen Daten - kann es was dafür? Nee, das liegt einfach daran das SMART kein Standard ist und jeder Hersteller die Attribute benutzt wie er möchte und oft auch nicht öffentlich macht wie man diese genau zu interpretieren hat.

Wobei es die Aufgabe des Hersteller der HDD/SSD ist, dies öffentlich zugänglich zu dokumentieren, dann können die Team welche Tools wie CrystalDiskInfo programmieren, die Unterstützung dafür auch einpflegen und sei es nur die korrekten Namen der Attrbute.

Du glaubst gar nicht auf was für ner kleinen Prio die SMART Implementation bei verschiedenen Controllerherstellern ist Die sehen zu, dass das SMART HEALTH Command und ne kleine handvoll Attribute einigermaßen funktionieren damit nicht fabriksneue Speicher gleich als fehlerhaft gemeldet werden, aber die Verwendung der einzelnen Attribute ist quasi wilder Westen. Viele sind auch absichtlich nicht dokumentiert. Dort gibts Dinge wie Attribute ohne Worst Byte - damit meine ich nicht auf 0 gesetzt, sondern dort fangen schon Rohdaten an und man hat quasi ein Byte mehr für die Rohwerte zur Verfügung. Es gibt Werte die durch mehr als 8 Bytes repräsentiert werden und auf mehreren Attributen verteilt werden - mit solchen Multiattributwerten kann keins der Standardtools umgehen. Oder bei Controllern aus der SSD Anfangszeit gibt es auch welche die haben statische SMART Daten nur damit die damaligen Tools aus HDD Zeit keine Fehlalarme schlagen können und die eigentlichen Nutzdaten sind in vendorspezifischen Bereichen außerhalb der Attribute, in den 512 Bytes an SMART Daten hat man einiges an Platz für Dinge außer den Attributen

SMART ist ein Wildwuchs und es wird nur noch schlimmer statt besser da keiner der Hersteller daran interessiert ist das zu standardisieren. Gedanke dabei ist nämlich, dass Hersteller ihre Produkte im professionellen Bereich auch damit bewerben, dass sie besser als die Konkurrenz Lebenszeitdaten erfassen können und damit Vorteile für Kunden bieten wenn es um die Beurteilung der Lebenszeit des Laufwerks geht. Spielt im Consumer Bereich keine Rolle, im professionellen Bereich dagegen schon.

Und bissle absurd wirds ja bei NVME Geräten. Dort gibts mit dem SMART Log ja ein inhaltlich am ATA SMART angelehntes Werk an Lebenszeitdaten aber das ist so allgemein gehalten das man kaum genau sagen kann, was mit der SSD falsch ist. Da sind herstellerspezifische Tools um die Custom Log Pages zu interpretieren quasi Pflicht.

Gerade bei dieser SSD bei der Aktuelle Wert bei vielen Attributen 0 ist ...

Die Thematik mit der 0 in Current/Worst/Threshold sehe ich ein klein wenig anders. Die Grundsatzfrage dabei ist ja, wie presse ich Lebenszeitdaten die keinen Maximumwert/Schlechtester Wert haben in das SMART Attribut Gerüst. Beispiel hochzählen der geschriebenen/gelesenen Sektoren etc. - was willst du da in Current/Worst /Threshold eintragen? Current und Worst haben logisch gesehen immer den gleichen Wert - da jeder Schreib/Lesevorgang ein neues Maximum setzt. Jetzt könnte man beide auf 100 setzten aber auf was machst du dann den Threshold? Es ist nicht möglich alleine aus der Maximalanzahl an Sektoren die geschrieben/gelesen werden dürfen die Lebenszeit zu beurteilen und damit ein Maximum festzulegen anhand dessen das Verhältnis von Current/Worst zu Threshold zu setzen wäre. Bei solchen reinen Countern finde ich alles außer den Rohwert zu nullen die einzig richtige Lösung, da damit klar angezeigt wird, dass es halt nicht wie ein "normales" SMART Attribut zu interpretieren ist.

 

[Holt]

Die Thematik mit der 0 in Current/Worst/Threshold sehe ich ein klein wenig anders.

Dann siehst Du es falsch, genau wie die Leute die diesen Mist in die FW programmiert haben. Deshalb kommt es einem dann als so ein Wildwuchs vor, weil es eben Leute gibt, die die Konventionen nicht einhalten und daher so einen Mist in der FW implementieren. Wenn man wirklich nicht weiß, wie man etwas in den Aktuellen Wert (was soll den der Maximumwert sein?) pressen soll, dann stellt man sie eben z.B. die bei vielen Micron und Crucial SSDs fix auf 100 ein und den Grenzwert auf 0, dann gibt es zumindest nie einen Fehlalarm von Tools die streng danach schauen, ob ein Aktueller oder Schlechtester Wert den Grenzwert erreicht haben. Was der Schlechteste Wert sein soll, ist auch klar definiert.

 

[Chuuei]

Dann siehst Du es falsch, genau wie die Leute die diesen Mist in die FW programmiert haben. Deshalb kommt es einem dann als so ein Wildwuchs vor, weil es eben Leute gibt, die die Konventionen nicht einhalten und daher so einen Mist in der FW implementieren. Wenn man wirklich nicht weiß, wie man etwas in den Aktuellen Wert (was soll den der Maximumwert sein?) pressen soll, dann stellt man sie eben z.B. die bei vielen Micron und Crucial SSDs fix auf 100 ein und den Grenzwert auf 0, dann gibt es zumindest nie einen Fehlalarm von Tools die streng danach schauen, ob ein Aktueller oder Schlechtester Wert den Grenzwert erreicht haben. Was der Schlechteste Wert sein soll, ist auch klar definiert.

Soso, FW Entwickler sehen es falsch, ich sehs falsch, deins ist die einzig richtige Sichtweise bei etwas, was in keinster Weise standardisiert ist und man machen kann was man will

Die normalisierten Werte fix auf 100/100/0 zu setzen suggeriert doch, dass der Wert wie ein normales SMART Attribut funktioniert, was es aber nicht tut. Dagegen hat 0/0/0 eine klare Aussage, das es eben nicht normal zu interpretieren ist. Ja das macht Probleme bei einigen Tools, aber wenn keiner sich die Mühe macht das zu standardisieren, brauch man sich auch nicht darüber zu beschweren das Hersteller das machen, was sie für sinnvoll halten. 0/0/0 hat auch den großen Vorteil, das die LTM Daten sich nicht widersprechen können. Manche Hersteller benutzen ein Attribut um die geschätze übrig gebliebene Lebensdauer anzugeben. Mal angenommen man hat eine SSD am Ende der spezifizierten Lebenszeit, unzählige Petabyte geschrieben und der Counter zur verbliebenen Lebenszeit steht bei 5% - und nun hat man Attribute mit den geschriebenen/gelesenen Sektoren mit 100/100/0 die suggerieren alles ist genauso frisch wie im Werkszustand Die widersprechen sich und es macht keinen Sinn. Widersprüche ist das was man tunlichst vermeiden will, egal wie rudimentär die SMART Daten sind.

Sicherlich sind die 0/0/0 keine perfekte Antwort für diesen Type von Attributen, aber die Hersteller haben sich schon dabei etwas gedacht es so zu lösen.

 

[Holt]

Dagegen hat 0/0/0 eine klare Aussage, das es eben nicht normal zu interpretieren ist.

Nein, denn es gibt Konventionen bei den S.M.A.R.T. Werten und die wichtigste davon ist, dass wenn der Aktuelle Wert den Grenzwert erreicht oder unterschreitet, der Zustand schlecht ist und darüber braucht man nicht zu diskutieren. Es ist ja auch nicht so, als wären die ganze Attribute bei denen die Aktuellen Werte bei der Revo gleich schon ab Werk auf 0 stehen, nicht auch normal interpretierbar. Bei den Programm- und Löschfehler haben andere FW Entwickler es auch geschafft da einen Aktuellen Wert von i.d.R. 100 zu vergeben und diesen entsprechend der Anzahl der aufgetretenen Fehler zu senken, dazu muss man nur definieren ab wie vielen Fehlern dies kritisch wird. Man kann ja wie es Seagate bei den Ende-zu-Ende Fehlern macht, pro Fehler um 1 runterzählen und den Grenzwert auf 99 setzen, so dass es ab dem ersten Fehler klar als kritisch zu erkennen ist, wobei dies bei den Programm- und Löschfehlern übertrieben wäre. Die sind im Grunde auch nicht so wichtig, denn wenn so ein Fehler auftritt, wird danach der NAND Block ausrangiert und wirklich über den Zustand informiert daher die Zahl der verbleibenden Reserveblöcke. Da weiß man wie viele vorhanden sind, wenn die SSD das Werk verlässt und kann dann leicht den Aktuellen Wert als Prozentangabe von diesen auslegen.

Für die gelesenen und geschriebenen Datenvolumen kann man ebenso einen Zielwert vorgeben, den man der SSD zutraut, bei den Betriebsstunden hat man dies ja auch getan, sonst wäre der Aktuelle Werte bei der ja nicht schon auf 98 gefallen.

Sicherlich sind die 0/0/0 keine perfekte Antwort für diesen Type von Attributen, aber die Hersteller haben sich schon dabei etwas gedacht es so zu lösen.

Nicht nur "keine perfekte Antwort", sondern die dümmste mögliche Antwort und gedacht hat sich dabei vielleicht jemand etwas, aber nicht jeder kommt beim Denken auch auf intelligente Lösungen.