SMART error (ErrorCount) detected auf Laptop-SSD

[mbit55]

Hallo,

bei Luxnote habe ich mir ein gebrauchtes Lenovo Thinkpad T570 gekauft und darauf
Debian Bullseye installiert, u.a. auch smartmontools.
Der Smartd Dämon sendet mir seitdem ab und zu Mails mit folgendem Inhalt:

Code: Alles auswählen

The following warning/error was logged by the smartd daemon:
Device: /dev/nvme0, number of Error Log entries increased from 1930 to 1932

Device info:
SAMSUNG MZVLB512HAJQ-000L7, S/N:S3TNNE0JB27773, FW:5L2QEXA7, 512 GB

For details see host's SYSLOG.

Im Syslog finde ich aber auch nicht mehr Information als obige Meldung.
Smartctl gibt folgendes aus:

Code: Alles auswählen

smartctl -a /dev/nvme0
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-18-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       SAMSUNG MZVLB512HAJQ-000L7
Serial Number:                      S3TNNE0JB27773
Firmware Version:                   5L2QEXA7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 512.110.190.592 [512 GB]
Unallocated NVM Capacity:           0
Controller ID:                      4
NVMe Version:                       1.2
Number of Namespaces:               1
Namespace 1 Size/Capacity:          512.110.190.592 [512 GB]
Namespace 1 Utilization:            63.390.081.024 [63,3 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 8b7100d65a
Local Time is:                      Tue Oct 11 21:28:20 2022 CEST
Firmware Updates (0x16):            3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x001f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Log Page Attributes (0x03):         S/H_per_NS Cmd_Eff_Lg
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     81 Celsius
Critical Comp. Temp. Threshold:     82 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     7.02W       -        -    0  0  0  0        0       0
 1 +     6.30W       -        -    1  1  1  1        0       0
 2 +     3.50W       -        -    2  2  2  2        0       0
 3 -   0.0760W       -        -    3  3  3  3      210    1200
 4 -   0.0050W       -        -    4  4  4  4     2000    8000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        29 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    2%
Data Units Read:                    17.652.301 [9,03 TB]
Data Units Written:                 41.821.921 [21,4 TB]
Host Read Commands:                 279.897.554
Host Write Commands:                608.119.944
Controller Busy Time:               1.883
Power Cycles:                       2.200
Power On Hours:                     2.446
Unsafe Shutdowns:                   123
Media and Data Integrity Errors:    0
Error Information Log Entries:      1.933
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               29 Celsius
Temperature Sensor 2:               28 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

Die Ausgabe von nvme error-log /dev/nvme0:
41812

Ich bin jetzt etwas ratlos, was von diesen Meldungen zu halten ist und ob
das ein möglicher Grund zur Reklamation wäre.

Viele Grüße
mbit55

[heisenberg]

Ich sehe da nur SUCCESS Meldungen. Insofern für mich kein Reklamationsgrund.

Ob das normal ist, dass das protokolliert wird, weiss ich nicht.

Gibt's bei SMART die Möglichkeit, das Loglevel zu setzen? (-> man smartctl oder google Smart+LogLevel...)

[cosinus]

Code: Alles auswählen

Data Units Written:                 41.821.921 [21,4 TB]

Hui.... 21 TB wurden auf das Drive schon geschrieben, ist nicht wenig finde ich, Warst du das, oder hat der Vorbesitzer das gemacht?

[heisenberg]

Code: Alles auswählen

Data Units Written:  ...  [21,4 TB]

Ja. 21 TB ist nicht wenig, erscheint mir aber für ein Gebrauchtgerät nicht außergewöhnlich hoch.

Per spontaner Google-Suche habe ich nicht direkt gefunden, wie viel dieses Modell(Samsung PM 981) verträgt.

256 GB Samsung SSD 970 Evo Plus verträgt 150 TB. Die ist aber in dieser Hinsicht vergleichsweise gut.

Stichworte für die Google Suche: DPWD oder TBW

[cosinus]

256 GB Samsung SSD 970 Evo Plus verträgt 150 TB. Die ist aber in dieser Hinsicht vergleichsweise gut.

Ok das ist recht viel. Aber die sind nicht automatisch unbrauchbar wenn dieser Wert erreicht ist oder?

[whisper]

Code: Alles auswählen

Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    2%

Scheint ja noch im grünen Bereich zu sein.
Bis Weihnachten hält die noch, dann kaufst du dir einfach ne neue +
Jedenfalls wäre mir das auf Dauer schon etwas unsicher

[mbit55]

Hallo,

Ich sehe da nur SUCCESS Meldungen. Insofern für mich kein Reklamationsgrund.

Mich irritieren die Werte bei

Code: Alles auswählen

Error Information Log Entries:      1.933

(inzwischen steht der Wert bei 1953) und bei der Ausgabe von

Code: Alles auswählen

nvme error-log /dev/nvme0
Error Log Entries for device:nvme0 entries:64

Das ist für mich widersprüchlich. Wo sind die anderen jetzt 1889 Fehler?

Code: Alles auswählen

Data Units Written:                 41.821.921 [21,4 TB]

Hui.... 21 TB wurden auf das Drive schon geschrieben, ist nicht wenig finde ich, Warst du das, oder hat der Vorbesitzer das gemacht?

Ich habe das Gerät erst seit einer Woche und ich glaube nicht, das durch die Installation von Debian und mit der Übernahme von Daten von meinem alten Rechner geschafft zu haben. Ich werde die Sache mal beobachten.

Stichworte für die Google Suche: DPWD oder TBW

Da finde ich mit der Modellnummer z.B. bei https://www.notebookcheck.com/Samsung-S ... 646.0.html die Information, dass es eine OEM-Version ist. Da werde ich wohl damit leben müssen, wenn ich das Gerät behalten will. Danke erst mal für die Infos.

Gruß mbit55

[heisenberg]

256 GB Samsung SSD 970 Evo Plus verträgt 150 TB. Die ist aber in dieser Hinsicht vergleichsweise gut.

Ok das ist recht viel. Aber die sind nicht automatisch unbrauchbar wenn dieser Wert erreicht ist oder?

Ich habe jetzt noch keine SSD erlebt, die tatsächlich dann nicht mehr ging, aber so grundsätzlich ist meine Vorstellung schon, dass eine SSD, dann mehr oder weniger Ihr Lebensende erreicht hat.

Beachte: Der TE hat eine SSD, die doppelt so viel Speicher hat. Dementsprechend höher ist da natürlich grundsätzlich der TBW-Wert(TBW => total bytes written).

Da finde ich mit der Modellnummer z.B. bei https://www.notebookcheck.com/Samsung-S ... 646.0.html die Information, dass es eine OEM-Version ist. Da werde ich wohl damit leben müssen, wenn ich das Gerät behalten will. Danke erst mal für die Infos.

Der Sinn dieses Absatzes erschließt sich mir nicht. Warum musst Du damit leben? Weil das kein Sachmangel ist und deswegen kein Grund für eine Rückgabe? Ich sehe gerade auch keinen Sachmangel und würde deshalb sagen: Ist doch alles Ok.

Hier sind ein paar Samsungs SSDs mit TBW Werten gelistet:

https://semiconductor.samsung.com/resou ... German.pdf

Wenn ich da bei einer Samsung 980 / 500 GB nachschaue, dann steht da: 300 TBW. Ob die hier vorliegende SSD, die zwar so ähnlich heisst wirklich ähnlich Werte hat, ist pure Vermutung/Hoffnung.

Hier ist noch eine Technische Spezifikation zu der SSD. Ich sehe aber keine direkte TBW/DWPD-Werte und mir ist es zu viel das Dokument genauer durchzulesen.

https://icecat.biz/p/samsung/mzvlb512ha ... 50705.html

[MSfree]

Ok das ist recht viel. Aber die sind nicht automatisch unbrauchbar wenn dieser Wert erreicht ist oder?

Heise hatte doch mal einige SSDs einem Lagzeittest ausgesetzt.
https://www.heise.de/newsticker/meldung ... 55009.html

Die sind auf über 9 Petabyte gekommen, was dem 60-fachen der Herstellerangabe entsprochen hat. Ich wäre da bzgl. der TBW-Angabe auch tiefenentspannt, wenn die Herstellerangabe überschritten ist.

[heisenberg]

Heise hatte doch mal einige SSDs einem Lagzeittest ausgesetzt.
https://www.heise.de/newsticker/meldung ... 55009.html

Die sind auf über 9 Petabyte gekommen, was dem 60-fachen der Herstellerangabe entsprochen hat. Ich wäre da bzgl. der TBW-Angabe auch tiefenentspannt, wenn die Herstellerangabe überschritten ist.

Ich habe da gerade mal durch die User-Kommentare des Artikels geblättert.

Dabei fiel mir dann dieser auf:

https://www.heise.de/forum/heise-online ... 2425/show/

TL;DR: Der Autor des Forums-Beitrages schreibt, dass ein erfolgreicher Schreibvorgang gar nichts beweist. Wesentlich ist, wie lange im Anschluß nach dem Schreibvorgang die Zellen noch zuverlässig Ihren Wert behalten.

Hier wäre also ein redundant ausgelegtes Dateisystem mit Prüfsummen(btrfs,ZFS) und regelmässigen Scrubs aufschlussreich.

Hier noch ein anderer:

https://www.heise.de/forum/heise-online ... 7260/show/

Ich verstehs nicht. Dieser Test ist völliger Quatsch. Das eigentliche Problem dieser Dinger ist die Zeit bis zu der die Daten einigermaßen stabil erhalten bleiben, bevor sie aufgrund von nachlassender Ladung in den Zellen nicht mehr lesbar sind.

Und diese Zeit ist von der Anzahl der Schreibzyklen abhängig. Was nutzt mir die Erkenntnis, daß ich da x Terabyte schreiben kann, wenn hinterher die Datenerhaltungszeit noch 10min beträgt.

N.B. Auch bei völlig neuen SSD's ist ein Jahr Datenerhaltung schon viel.. Da kommt es höchstens noch darauf an wie wirkungsvoll der interne Refreshmechanismus des Herstellers ist - und der funktioniert auch nicht im Schrank, sondern nur unter Spannung!.

Ich lese: SSDs sind wohl scheinbar überhaupt nicht dafür geeignet, sie als Datensicherung in den Schrank zu legen. (Das wäre doch mal ein interessanter Test: ZFS -> SSDs in den Schrank und nach 1,2,6,12 Monaten rausgeholt und einen Scrub gemacht).

Ich denke, ich werde mal alle SSDs, die ich im Einsatz habe, auf ZFS umstellen und regelmässige Scrubs machen.

---

Insgesamt hört sich das für mich wie ein ziehmlich dramatisches Problem an, was mich sehr wundert. Denn dass Daten über 1 Jahr auf einer SSD nicht verändert werden, würde ich jetzt mal als recht normalen Fall einstufen. Insofern erzählt deep_purple da entweder Mist, oder es ist tatsächlich ein großes Problem.

[MSfree]

TL;DR: Der Autor des Forums-Beitrages schreibt, dass ein erfolgreicher Schreibvorgang gar nichts beweist. Wesentlich ist, wie lange im Anschluß nach dem Schreibvorgang die Zellen noch zuverlässig Ihren Wert behalten.

Der Leser hat nicht verstanden, wie Flash funktioniert und fabuliert seinerseits völlig esoterisches Zeug daher. Jedenfalls hatte ich bisher nicht die Chance, das Problem der Datenerhaltung nachzuvollziehen. Ich nutze jetzt rund 25 Jahre Flashspeicher und bisher hat sich noch keiner durch Langzeitlagerung selbst gelöscht. Wie sollte denn sonst so ein Test ablaufen?

Vollschreiben, 25 Jahre warten, lesen versuchen?

Im Test ging es darum, wann die Flashzellen soweit verschlissen sind, daß sie nicht mehr genullt (gelöscht) werden können. Erfolgreich beschrieben hält Flash seine Daten sehr sehr lange.

Irgendwo liegt noch die originale 8MB (ja, wirklich Megabyte) CF-Karte rum, die seinerzeit mit der Kodak DC260 mitgeliefert wurde, rumliegen. Die kann ich ja mal versuchen, auszulesen.

Klar, es gibt immer selbsternannte Spezialisten, die solche Tests diskreditieren wollen. Auf die gebe ich aber nichts, zumal das meiner Erfahrung mit Flashspeicher in allen Punkten widerspricht.

[heisenberg]

Der Leser hat nicht verstanden, wie Flash funktioniert und fabuliert seinerseits völlig esoterisches Zeug daher. Jedenfalls hatte ich bisher nicht die Chance, das Problem der Datenerhaltung nachzuvollziehen. Ich nutze jetzt rund 25 Jahre Flashspeicher und bisher hat sich noch keiner durch Langzeitlagerung selbst gelöscht. Wie sollte denn sonst so ein Test ablaufen?

Du unterstellst dem Kommentarschreiber das fabulieren von völlig esoterischem Zeug und Unverständnis in Bezug auf die Flash-Funktionsweise, nur um im nächsten Absatz zu schreiben, dass Du es nur nicht nachvollziehen kannst, d. h. Du gibst selbst Deine eigene Unkenntnis in Bezug auf die detaillierte Funktionsweise von Flash/SSD zu. Habe ich Dich da richtig verstanden?

Wenn es da schon mal 2 Personen gibt, die das gleiche schreiben, dann sinkt für mich die Wahrscheinlichkeit, dass beide Blödsinn schreiben schon etwas. Kann natürlich sein, dass beide sich aus der gleichen Quelle informiert haben.

[Tintom]

Wenn es da schon mal 2 Personen gibt, die das gleiche schreiben, dann sinkt für mich die Wahrscheinlichkeit, dass beide Blödsinn schreiben schon etwas. Kann natürlich sein, dass beide sich aus der gleichen Quelle informiert haben.

Wenn dem so wäre, müssten sämtliche USB-Sticks und Speicherkarten in meinem Besitz schon kaputt sein. Die benutze ich nämlich nur alle paar Jahre mal. Ich sage damit nicht, dass Flashchips nicht altern, aber das Argument "Ein Jahr ist schon viel" geht m.E. doch hart an der Realität vorbei.

[MSfree]

Wenn es da schon mal 2 Personen gibt, die das gleiche schreiben, dann sinkt für mich die Wahrscheinlichkeit, dass beide Blödsinn schreiben schon etwas.

Oder einfach nur Trolls.

[heisenberg]

Ich hatte durchaus schon USB-Sticks, die ich ne weile irgendwo rumliegen hatte und die, als ich sie mal wieder auslesen wollte, einfach nicht mehr lesbar waren. Aber auch hier Zustimmung: Das war weit abseits der 1-Jahres-Marke.

[DeletedUserReAsG]

Ich wäre da bzgl. der TBW-Angabe auch tiefenentspannt, wenn die Herstellerangabe überschritten ist.

und

Ich nutze jetzt rund 25 Jahre Flashspeicher und bisher hat sich noch keiner durch Langzeitlagerung selbst gelöscht. Wie sollte denn sonst so ein Test ablaufen?

Es ist im Grunde so: je häufiger die Zellen neu geschrieben werden, desto größere Leckströme gibt es, und um so schneller verlieren einzelne Zellen Teile der Ladung, was bei MLC halt dazu führt, dass einzelne Bits kippen – je mehr Level, desto weniger Ladung muss dafür verlorengehen. Je nachdem, wo sie kippen, bekommt man das lange Zeit nicht mit, wenn man nicht genau darauf schaut – etwa mittels Backuplösung, die mit Prüfsummen arbeitet. Sind wohl schon einige Leute aus ihren Wolken gefallen, als beispielsweise restic sie darüber informierte, dass die Backups korrupt sind.

Die Heisemänner hätten nach dem Test die noch nutzbaren Devices mit einem Muster beschreiben, und das hashen sollen. Dann hätten sie die Dinger in den Schrank legen, und nach einem Monat oder so wieder auslesen und vergleichen sollen. Ich behaupte: so richtig Entspannung wäre da nicht mehr aufgekommen …

[mbit55]

Da finde ich mit der Modellnummer z.B. bei https://www.notebookcheck.com/Samsung-S ... 646.0.html die Information, dass es eine OEM-Version ist. Da werde ich wohl damit leben müssen, wenn ich das Gerät behalten will. Danke erst mal für die Infos.

Der Sinn dieses Absatzes erschließt sich mir nicht. Warum musst Du damit leben? Weil das kein Sachmangel ist und deswegen kein Grund für eine Rückgabe? Ich sehe gerade auch keinen Sachmangel und würde deshalb sagen: Ist doch alles Ok.

Ich wollte damit ausdrücken, dass mir eine Platte mit weniger intensivem Vorleben lieber gewesen wäre, aber, wie Du richtig erkannt hast, das kein Reklamationsgrund ist. Und für den Fall der Fälle bietet Luxnote ja auch Garantie und Gewährleistung auf gebrauchte Geräte.
Ich habe mir mal die Smart-Werte der Festplatte in meinem alten Laptop angeschaut (2011 als Neugerät angeschafft, HDD mit 500 GB). Bei Total_LBAs_Written steht da 3663301138. Wenn ich das mit der physischen Sektorgröße von 4096 Bytes multipliziere, komme ich so auf ca. 14 TB. Ich glaube nicht, dass sich mein Nutzungsverhalten in den nächsten Jahren gravierend ändern wird. Deshalb denke ich, dass die Platte in dem Thinkpad zumindestens wegen der maximalen TBW-Kapazität länger als bis Weihnachten durchhalten wird.
Oder kann man das nicht so vergleichen?

Gruß mbit55

[wanne]

Je nachdem, wo sie kippen, bekommt man das lange Zeit nicht mit, wenn man nicht genau darauf schaut – etwa mittels Backuplösung, die mit Prüfsummen arbeitet. Sind wohl schon einige Leute aus ihren Wolken gefallen, als beispielsweise restic sie darüber informierte, dass die Backups korrupt sind.

Moderne Dateisysteme haben doch selbst Checksummen und melden die Fehler. Außerdem führen die Festplatten selbst welche und betreiben Fehlerkorrektur. Normale Festplatten zeigen das auch an. (Die genannte offensichtlich nicht...) Kommt bei mir eigentlich nie vor, dass es da ärger gibt. Das sieht auf USB-Sticks ganz anders aus.

[DeletedUserReAsG]

Kommt bei mir eigentlich nie vor, dass es da ärger gibt.

Das ist sehr schön für dich, trifft halt nur nicht auf jeden zu. Was moderne Dateisysteme machen, ist auch nicht so die Referenz, wenn die Leute gerade auch für Backupzwecke auf die bewährten ext-Dateisysteme setzen.

Der Entwickler von Restic hat sich mal in einem Podcast dazu geäußert, wie die irritierten User ihn kontaktiert haben, als das Programm Prüfsummenfehler bei den Backups gemeldet hat.

[wanne]

Das ist sehr schön für dich, trifft halt nur nicht auf jeden zu.

Ich schubse ne Menge Disks diverser Hersteller durch die Gegend und kann sagen, dass fehlerhafte Daten auf HDDs deutlich häufiger sind als auf SSDs. Aber ich habe natürlich SMART-Monitoring und wenn da irgend was vorfällt wird ersetzt. Das ist etwas anderes wie Otto normal der erst mal überhaupt ins smart gucken muss und sich die neue Disk von seinem eigenen Geld kaufen muss. (Da haben wir aber natürlich aber auch mehr davon, die dafür weniger genutzt werden...)

Was moderne Dateisysteme machen, ist auch nicht so die Referenz, wenn die Leute gerade auch für Backupzwecke auf die bewährten ext-Dateisysteme setzen.

Zumindest auf Metadaten supportet ext4-Checksummen. Wenn die Fehler zu häufig werden geht das nicht ganz ungesehen.

[heisenberg]

Ich schubse ne Menge Disks diverser Hersteller durch die Gegend und kann sagen, dass fehlerhafte Daten auf HDDs deutlich häufiger sind als auf SSDs.

Und Du setzt idR auf allen SSDs btrfs ein, wie ich das bei Dir vermuten würde?

[wanne]

Und Du setzt idR auf allen SSDs btrfs ein, wie ich das bei Dir vermuten würde?

Zuhause ja. Auf der Arbeit muss ich mich hauptsächlich mit Quobyte/XtreemFS-XFS Ceph und BeeGFS-ZFS rum schlagen.

[heisenberg]

Und Du setzt idR auf allen SSDs btrfs ein, wie ich das bei Dir vermuten würde?

Zuhause ja. Auf der Arbeit muss ich mich hauptsächlich mit Quobyte/XtreemFS-XFS Ceph und BeeGFS-ZFS rum schlagen.

Die Frage zielt natürlich darauf ab, ob Du in allen Anwendungsfällen auch tatsächlich Datenfehler in den Speichergeräten erkennst; d. h. wie also die tatsächliche Basis für die Aussage: "Ich sehe mehr Fehler auf HDDs als auf SSDs" ist.

[DeletedUserReAsG]

Ich schubse ne Menge Disks diverser Hersteller durch die Gegend und kann sagen, dass fehlerhafte Daten auf HDDs deutlich häufiger sind als auf SSDs.

Wie gesagt: schön für dich. Mir käme nicht die Idee, das, was ich beruflich mache auf Privathansel zu übertragen. Im konkreten Kontext meiner von dir zitierten Antwort ging es auch eher um die „data retention“ (stromlos) von durchgeschriebenen MLC-SSDs – in diesem Kontext ist deine Erfahrung mit Enterprise-Kram und aktiver Datenhaltung nicht mehr, als eine nette Anekdote.

Zumindest auf Metadaten supportet ext4-Checksummen.

Dann rechne mal scharf nach: Verhältnis Metadaten zu Nutzdaten, und daraus abgeleitete Menge an unentdeckten Fehlern durch „bit rot“ beim ersten Auftreten eines Prüfsummenfehlers in den Metadaten. 1:100k? 1:1M? 1:1G?

[MSfree]

Prüfsummen sind nett, bringen aber erst in dem Moment etwas, wenn man auf die Datei zugreifen will. Wenn das ein Spielfilm ist, den ich vor 8 Jahren mal aufgenommen habe und jetzt erst sehen will, weiß ich zwar, daß die Datei kaputt ist, aber ich weiß nicht, seit wann.

Ich kann mir auch nicht vorstellen, daß auf riesigen Datenvolumes (ab 100TB) die Prüfsummen des kompletten Datenbestands regelmässig berechnet und verglcihen werden. Bei 100TB würde das selbst auf superschnellen SSDs locker einen Tag dauern, bei Festplatten mehrere Monate.