GrumpyCat schrieb:
Die zwei Slots erlauben Failover, z.B. falls ein Update der Firmware unterbrochen wurde. So wie Dual BIOS bei Mainboards. Die ADATA wäre bei einem fehlgeschlagenen FW-Update hin, die Intel nicht.
Dein beschriebener Failover hat nicht mit den zwei Slots zu tun. Schon seit Jahren wird bei allen Herstellern die FW nicht nur an einer Stelle in den Flash geschrieben sondern an mehreren, um genau dort eine Redundanz für Fehler zu haben. Mehrere FW Slots bei NVMe Devices kommt ursprünglich aus dem Enterprise Bereich und wird dort in verschiedenen Szenarien genutzt (Das wird auch der Grund sein warum Intel, welches ja Enterprise SSDs anbietet das in der FW drin hat. Die FW wird ja auch nicht für jede SSD komplett neu geschrieben). Dein Dual Bios Vergleich stimmt aber wohl in der Hinsicht, dass du natürlich zwei verschiedene Konfigurationen fahren kannst die man bei Bedarf umschaltet.
GrumpyCat schrieb:
Soll das eine Begründung sein, weswegen man in einem Test die Sachen auch gar nicht erwähnen sollte?
Das habe ich doch gar nicht geschrieben? Ich habe gesagt, dass nur weil sich SSDs in Features unterscheiden, man doch deshalb nicht automatisch sagen kann das eine ist besser als das andere. Das was du angedeutet hattest.
GrumpyCat schrieb:
Das ist ein grundlegendes Feature des SMART-Standards. Ich benutze das seit zwei Jahrzehnten bei allen meinen Platten automatisiert regelmäßig im Hintergrund.
Interessant, NVMe als Protokoll gibts gerade mal knapp 9 Jahre oder willst du andeuten, dass SMART für ATA Devices und SMART bei NVMe das gleiche ist? Das ist nämlich mit nichten der Fall. Das SMART Log bei NVMe hat aber wohl das gleiche Grundproblem was schon das SMART bei ATA Devices hat - die Hersteller wollen sich nicht in die Karten blicken lassen und setzen auf herstellereigene Attribute (im Fall von ATA SMART) bzw. Custom Log Pages (im Fall von NVMe) für die wirklich technisch interessanten Werte, welche dann nur mit den herstellereigenen Tools komplett interpretiert werden können. Aber auch um Endkunden vor falschen Schlussforderungen zu schützen .
Einfach mal als Beispiel das NVMe Error Log. Die Anzahl an Error Log Entries wird im SMART Log festgehalten, aber mit den eigentlichen Error Log Entries kann ein Endkunde gar nichts anfangen. Die Command IDs kann man als technisch versierter User noch in der NVMe Spec nachgucken um zu sehen was für eine Art Kommando den Fehler ausgelöst hat, aber wenn man dann die Ursache wissen will, brauch man nen Trace der PCIe Kommunikation - es gibt keinen anderen Weg die Infos sonst komplett zu interpretieren. Und ne steigende Anzahl an Fehlern suggeriert doch erstmal ein Problem oder? Kann, muss aber nicht sein, wie z.B. im Fall das der Linux Treiber standardmäßig TCG bezogene Kommandos beim booten schickt und wenn die SSD das nicht unterstützt wird sofort ein Error Log Entry erzeugt obwohl mit dem Device alles in Ordnung ist. Einfach mal als Beispiel warum beim NVMe SMART Log das interpretieren genauso wenig einfach ist wie beim ATA SMART. Oder auch bei deiner Aussage zum Temperature Threshold:
GrumpyCat schrieb:
hat wesentlich höhere Temperatur-Thresholds (ob das mal so gut ist...)
Das sind die Schwellen ab denen das Device throttelt um nicht zu heiß zu werden - warum sollten da höhere Werte schlechter sein? Je höher diese sind, umso heißer darf das Gerät werden bevor es drosselt, es heißt nicht dass das Gerät heißer wird.
Die eigentliche Idee, festzuhalten welche Features ein Produkt beim Test hat, durch Präsentation von Device Capabilities und SMART Werte ist durchaus gut. Aber ich persönlich finde man sollte unbedingt darauf achten , dass man nicht zu Halbwissen einlädt, weil es eben nicht trivial ist die gezeigten Werte zu interpretieren.
Siehe als aktuelles Beispiel auch dieses Thema hier im Forum:
https://www.computerbase.de/forum/threads/ssd-stribt-warum.1996088/
Dort wird einem User ein Tausch der SSD ans Herzen gelegt obwohl diese technisch einwandfrei ist... Verursacht durch Halbwissen wie SMART Werte zu interpretieren sind.