NVMe Grundlagen

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

NVM Express (NVMe) ist eine auf SSDs optimierte Schnittstelle (Register-Level-Interface) für den PCIe Bus. Die Spezifikation an sich ist nicht auf SSDs limitiert, sondern allgemein auf non-volatile (persistente) Speicher ausgelegt. Das Protokoll wurde mit Augenmerk auf optimierte Kommando-Verwaltung (Submission und Completion) entwickelt. Aufgrund der hohen Geschwindigkeit von PCIe SSDs wurde außerdem darauf geachtet, dass möglichst viele Kommandos parallel abgearbeitet werden können. Wichtiger Hinweis: Die SSDs sind zwar über den PCIe Bus angebunden, als Protokoll wird aber NVMe eingesetzt.

Hauptmerkmale

Das NVMe Interface besitzt folgende Key Attribute:[1]

  • Vereinfachtes Command Set

10 Admin und 3 I/O Kommandos, die als "required" eingestuft sind.

  • Queuing Model

Unterstützung für bis zu 64K I/O Queues mit jeweils 64K in flight Kommandos per Queue. Zusätzlich können den einzelnen Queues Prioritäten zugewiesen werden. Bei NVMe unterscheidet man zwischen Submission Queues und Completion Queues. In der Submission Queues werden Nachrichten vom Host zum Controller abgesetzt, in der Completion Queue vice versa (z.B. um Completion von I/O zu signalisieren). Diese Queues sind in Multi-CPU Architekturen sehr effizient, da es pro Core zugeordnete Queues und Interrupts gibt.

NVMe Command Execution

  • MSI-X Interrups

Erlauben mehr Interrupts per Device und gezieltere Interrupts in Multi-CPU Umgebungen.[2]

  • Mehrere Namespaces per Device

Ein NVMe Device kann in unterschiedliche Namespaces eingeteilt werden, die eine logische Einheit bilden. Reservations

  • Multipath I/0

Dual Port SSDs oder SSDs hinter PCIe Switches können an mehrere Hosts angebunden werden. Dabei werden pro Namespace eindeutige IDs generiert, die die Hosts unterscheiden.

  • Autonome Power States

Ohne Management durch ein OS werden Power State Wechsel vollzogen.

  • Geringere Latenzen

Die Verringerung der Latenzen lässt sich auf das effizientere Absetzen von Kommandos zurückführen. Im Gegensatz zu AHCI müssen bei NVMe keine Register zum Absetzen von Kommandos ausgelesen werden. Bei NVMe genügt es, die neuen Werte in die Queues zu schreiben.[3]

Performance

Die PCIe Schnittstelle liefert von sich aus eine hohe Performance und eignet sich daher ideal für SSDs:

  • ~1 GB/s per Lane (Gen3), z.B. bei 8-fach PCIe 3.0 8GB/s pro Device
  • Latenzen von 10us bis 3 us
  • Direkte Anbindung an CPU (Gen3) und nicht über Chipset (Gen2)

Fully Exploiting Next Generation NVM

Linux Historie

Vgl. History of NVMe in Linux (intel.com):

  • Kernel 3.3 2011, Merge in Mainline 2012 (NVMe 1.0c)[4]
  • Kernel 3.6, Supports blocks greater than 512 byte
  • Kernel 3.9, Discard/Trim
  • Kernel 3.10, Bio Splitting
  • Kernel 3.12, Power Management: Suspend/Resume
  • Kernel 3.14, Controller Failure and Recovery
  • Kernel 3.15, Hot Plug CPU
  • Kernel 3.16, Flush
  • Kernel 3.19, blk-mq Driver[5]
  • Kernel 4.0, device-mapper multipath
  • Kernel 4.1, Data integrity extensions

Formfaktoren

M.2

Der Schnittstellen-Formfaktor M.2 ist vor allem im Client-Bereich verbreitet.[6] Der Standard löst die mSATA Schnittstelle ab, da M.2 flexibler in Bezug auf Verwendung und Schnittstellen-Vielfalt ist.[7]

U.2 2,5" (SFF-8639)

Die U.2 Schnittstelle wurde bis vor kurzem als SFF-8639 bezeichnet, die Schnittstelle nimmt NVMe SSDs im 2,5" Format auf. In Client-Umgebungen ist U.2 noch nicht sehr verbreitet, zur Konvertierung auf U.2 gibt es aber M.2 zu U.2 Adapter.[8] Diese Adapter konvertieren oft auf miniSAS HD Stecker, welche wiederum per Kabel auf U.2 Stecker enden. Ein weiterer Vorteil von U.2 ist außerdem, dass der Stecker zu SATA, SAS und SATA Express kompatibel ist.[9]

Basic PCI Express SSD Topology – 3 Connector

Add-In (PCIe)

SSDs für PCIe-Slots sind der traditionelle Weg für NVMe SSDs als Add-In Karte.[10][11] Vor der NVMe-Spezifikation nutzten PCIe-SSDs zwar den selben Slot, wiesen aber kein standardisiertes Interface auf.

Einzelnachweise

Foto Georg Schönberger.jpg

Autor: Georg Schönberger

Georg Schönberger, Abteilung DevOps bei der XORTEX eBusiness GmbH, absolvierte an der FH OÖ am Campus Hagenberg sein Studium zum Bachelor Computer- und Mediensicherheit, Studium Master Sichere Informationssysteme. Seit 2015 ist Georg bei XORTEX beschäftigt und arbeitet sehr lösungsorientiert und hat keine Angst vor schwierigen Aufgaben. Zu seinen Hobbys zählt neben Linux auch Tennis, Klettern und Reisen.


Das könnte Sie auch interessieren

CHS und LBA Adressierung von Festplatten
Funkmaus ruckelt
PCI Express