smartctl-Selbstest mit NVME

linuxnutzer

Commander
Registriert
Dez. 2011
Beiträge
2.893
$ sudo smartctl -a /dev/nvme1
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.11.0-29-generic] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number: Lexar SSD NM790 1TB
...
Num Test_Description Status Power_on_Hours Failing_LBA NSID Seg SCT Code
0 Extended Completed without error 27 - - - - -
1 Short Completed without error 27 - - - - -

Der Befehl dauert unter 1 Minute:

sudo smartctl -t long /dev/nvme1

"-t long" und "-t short" dauern etwa gleich lang. Die 4TB-Variante ist schneller fertig.

Kann man NVME mit smartctl nicht testen?
 
Die normalen self tests lesen meines Wissens nach für NVME drives nur den aktuellen Datenstand aus.

Für NVME gibt es laut Dokumentation

https://www.smartmontools.org/wiki/NVMe_Support

smartctl - A

wenn es smartmontools sein sollen. Wobei die Testfunktionen hier auch andere sind als bei spinning rust. Ansonsten gibt es auch noch ein paar Funktionen via nvme-cli
 
  • Gefällt mir
Reaktionen: madmax2010 und linuxnutzer
SpartanerTom schrieb:
Die normalen self tests lesen meines Wissens nach für NVME drives nur den aktuellen Datenstand aus.

Also kein intensiver Selbstest? Die Smart-Werte interessieren mich nicht.

linuxnutzer schrieb:

Darum geht es mir

jodd2021 schrieb:
Ist die Ausgabe gekürzt oder ist das alles?

Gekürzt, ich wollte nur das Testergebnis zeigen.

zcomputerbasez schrieb:
Evtl. besser nvme-cli als smartctl mal probieren?

Gibt es da einen intensiven Test? Es geht nicht um Werte auslesen.
 
Die Frage ist halt auch was genau damit bezweckt werden soll. Bei HDDs ist das ja technisch eine ganz andere Geschichte. Bei Flash-Speichern macht das ja eigentlich der Speichercontroller der auch das Wear-Leveling betreibt. Ein separater test ist da meines Wissens nach nicht nötig.
 
  • Gefällt mir
Reaktionen: zcomputerbasez und linuxnutzer
Diese SMART Selbsttests sind schon immer extrem Geräteabängig. Jeder Hersteller kann da entscheiden was er machen will. Genau wie bei den Löschfunktionen etc.

Da NVMes ganz anders aufgebaut sind, wesentlich schneller sind und keine beweglichen Teile haben könnte DEINE NVMe das tatsächlich einfach so implementiert haben. Ein ander Hersteller oder ein anderes Modell könnte das wieder ganz anders machen...
 
  • Gefällt mir
Reaktionen: zcomputerbasez, linuxnutzer und kieleich
smartctl unterstützt nvme nur recht rudimentär

das nvme tool ist dafür nicht besonders anwender freundlich

dann muss bei HDDs immer alles getestet werden. bei nvme nur die zellen die tatsächlich, daten enthalten. wo keine daten sind kann auch nicht getestet werden

und da keine daten rausgeleitet werden müssen könnten diese tests sehr parallel statt finden und somit auch sehr schnell fertig sein. ganz unabhängig von dem pci interface und dessen geschwindigkeit

wenns dir nicht gut genug ist bleibt der klassische test mit tatsächlich vollschreiben und auslesen a la h2testw oder badblocks, aber dann verbrennst du schreib zyklen
 
  • Gefällt mir
Reaktionen: zcomputerbasez und linuxnutzer
Danke euch für die Erklärungen.

Ray519 schrieb:
Diese SMART Selbsttests sind schon immer extrem Geräteabängig.

Ich habe da eine Samsung SSD 860 EVO 500GB da hat der lange Test ca. 2h gedauert, obwohl keine Partition angelegt war.

Die Lexar dürften da völlig anders sein, die sind sofort fertig, wenn es keine Partition gibt. Mit Partitionierung und Daten geht es aber auch sehr schnell, vielleicht 2 Minuten.

SpartanerTom schrieb:
Bei HDDs ist das ja technisch eine ganz andere Geschichte.

Ok, mir geht es nur darum, dass ich neuen Speicher gerne vorher teste.

kieleich schrieb:
wenns dir nicht gut genug ist bleibt der klassische test mit tatsächlich vollschreiben und auslesen a la h2testw oder badblocks,

ok. Dann verwende ich f3 - Fight Flash Fraud zum Testen wie bei SD-Karten.

https://fight-flash-fraud.readthedocs.io/en/stable/
 
  • Gefällt mir
Reaktionen: zcomputerbasez
linuxnutzer schrieb:
da hat der lange Test ca. 2h gedauert, obwohl keine Partition angelegt war.
Partitionierung hat ja auch völlig egal zu sein für solche Tests. Weil es ist das Gerät das sich selbst testet. Und das ist reiner "Block" Speicher. Der völlig unabhängig von sogar der Partitionstabelle ist. Geschweige denn einem Dateisystem.

Das könnte bei Remappenden Geräten höchstens davon abhängen, wie viel Speicher denn remapped / beschrieben wurde.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: linuxnutzer
Ich habe jetzt im UEFI einen NVME-Selbstest entdeckt. Der scheint dann mit smartctl unter extended auf.

Die NVME mit Partitionierung dauern eindeutig länger.

Man muss sich überlegen, ob man mit f3 testen und vergleichen will. Das verkürzt natürlich die Lebenszeit.
 
linuxnutzer schrieb:
Die NVME mit Partitionierung dauern eindeutig länger.
Nicht die Partitionierung, sondern die Datennutzung.

Denn eine komplett Cleane SSD weiß normalerweise dass sie leer ist. Egal nach welcher Speicheradresse gefragt wird, sie braucht noch nicht mal den Speicher zu lesen, und kann quasi immer 0 antworten.

Wenn Speicher belegt ist, dann muss die SSD für alle diese Bereiche halt wirklich ihren Speicher lesen. Das ist etwas das klassische HDDs nicht machen. Aber zB SMR HDDs auch machen.

Wenn der Selbstest also so gebaut ist, dass er nur Nutzerdefinierten Speicher testet oder zB Nur belegten Speicher ließt (und zB mit Checksummen checkt, ob der Inhalt noch der gleiche Ist), dann würde das das natürlich beeinflussen. Und unbelegter Speicher hat keine Daten die man auf Konsistenz Checken könnte.
Und schreiben will der Hersteller vermutlich vermeiden. Ist vermutlich sogar nicht erlaubt, denn sonst würde der Selbsttest Datenverlust bedeuten, wenn da Nutzersichtbare Speicherbereiche überschrieben werden.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: linuxnutzer und zcomputerbasez
Zurück
Oben