qiller schrieb:
Kann das wer erklären, warum man als OS-Hersteller sowas macht? Oder gehts hier noch um was anderes, was ich hier übersehe?
Nachdem sich nun alle Welt über dieses Thema seit ein paar Tagen aufregt, habe ich mal versucht mich durch die Micorsoft Doku zu wühlen, und das Thema zu verstehen.
Erst mal grundsätzlich: Betriebsysteme arbeiten immer mit irgendwelchen Abstraktionsschichten.
So sollte einen Filesystemtreiber (das ist die Schicht, die oberhalb des Gerätetreibers ein Speichermedium verwaltet und in Dateien und Verzeichnissen organisiert, bei Windows also NTFS und (ex)FAT) geräteunabhängig mit der Ebene darunter kommunizieren.
Also im Prinzip sollte es dem Fillesystemtreiber "egal" sein, ob das Medium eine NVME SSD, eine SATA SSD/HDD, ein USB Stick oder eine SD-Karte ist.
Problem mit allen Abstraktionsschichten ist aber, dass sie zum einen Leistung kosten, und zum anderen spezielle Merkmale des Gerätes darunter verbergen. Man muss daher bei solchen Schichten immer irgendeine Art Kompromiss eingehen.
Eine Lösung ist z.B. bestimmte geräteklassen spezifische Funktionen (wie etwa TRIM bei allen Flash basierten Medien) in abstrakter Form anzubieten. Dann kann der Filesystemtreiber seine Funktion anpassen (also wenn er ein Flash Medium erkennt, dann sendet er auch TRIM Kommandos).
Über die Jahrzehnte haben sich viele Geräte weiterentwickelt. Ursprünglich hatten Block-Geräte Treiber nur Funktionen um Blöcke (Sektoren) zu lesen und zu schreiben, und ein paar generische Steuerfunktionen (ioctl) um z.B. die Kapazität abzufragen. Als dann die Speichergeräte "intelligenter" wurden, z.B. durch die Fähigkeit mehrere Schreib/Lesevorgänge zu sammeln und optimiert auszuführen (NCQ - Native Command Queing) musste man die Abstraktionsschichten um entsprechende Möglichkeiten erweitern und auch die Filesysteme mussten in der Lage sein, entsprechende Requests zu erstellen.
Nun zu Windows:
Seit Windows Server 2003 gibt es bei Windows die
Storport Schnittstelle.
Sie ist als Alternative zur SCSI-Port Schnittstelle für "leistungsfähige" Speichergeräte (Anfangs RAID Controller oder Fibre Channel Fabrics) gedacht und bietet entsprechende Möglichkeiten.
Diese Schnittstelle wurden dann mit neueren Windows Versionen zunehmend erweitert.
Windows nutzt aber für die Kommunikation mit Storport SRB (SCSI Request Blocks), d.h. für Windows ist SCSI der Abstraktionslayer für die Kommunikation mit dem Speichergerätetreiber.
Unterhalb der Storport Ebene gibt es, wie bei Windows auch in anderen Bereichen, die "Miniport" Treiber, und einer davon ist der
StorNVMe Miniport Treiber
Dort gibt es auch den SCSI zu NVMe Translation Layer. Grundsätzlich sind NVMe und SCSI Befehle relativ ähnlich, und es gibt auch eine offizielle Translation Reference.
StorNVMe unterstützt auch viele
NVMe Features, ob jetzt "alle" kann ich nicht sagen.
Wichtig ist auch die Unterstützung für
BypassIO, was die Grundlage für DirectStorage ist:
Da NVMe SSDs als PCIe Busmaster auf den ganzen Speicher zugreifen können (sofern ihnen der Zugriff per IOMMU erlaubt ist...) können sie damit selbstständig große Datenblöcke z.B. in den Userspace oder das GPU VRAM kopieren.
Wie man sieht, ist es also keineswegs so, dass Windows NVMe Geräte bisher wie eine SCSI HDD behandelt hat, sondern es hat umfassende Unterstützung dafür. Nur werden halt zur Kommunikation zwischen den Abstraktionsschichten teilweise die SRBs verwendet. Anscheinend hat Microsoft hier nun eine Optimierung vorgenommen, weil mit zunehmend schnelleren SSDs dieser Layer anfing immer mehr zu bremsen.
. Mir fiel keine bessere Methode ein, daher hatte ich es nicht erwähnt.
)
.
