Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Navigation
Bezieht sich auf SUSE Linux Enterprise Server 12 SP5

24 Permanenter Speicher

Dieses Kapitel enthält weitere Informationen zur Verwendung von SUSE Linux Enterprise Server mit nicht-flüchtigem Hauptspeicher, auch als Permanenter Speicher bekannt, der aus einem oder mehreren NVDIMM besteht.

24.1 Einführung

Ein permanenter Speicher ist eine neue Art von Speicherung am Rechner. Er kombiniert annähernd so hohe Geschwindigkeiten wie bei normalen dynamischen RAMs (DRAMs) mit der Byte-für-Byte-Adressierbarkeit des RAM und der Permanenz von Solid-State Disks (SSDs).

Wie bei herkömmlichen RAMs wird er direkt am Speichersteckplatz der Hauptplatine installiert. Damit wird er im selben physischen Formfaktor bereitgestellt wie RAM – als DIMMs. Man nennt sie NVDIMMs: Non-Volatile Dual Inline Memory Modules.

Im Unterschied zu RAM ist ein permanenter Speicher in vielerlei Hinsicht Flash-basierten SSDs ähnlich. Beide basieren auf unterschiedliche Weise auf dem Stromkreis von Festkörperspeichern, bieten aber unabhängig davon einen nicht-flüchtigen Speicher. Dies bedeutet, dass ihre Inhalte beibehalten werden, wenn das System heruntergefahren oder neu gestartet wird. Bei beiden Varianten geht das Schreiben von Daten langsamer von statten als das Lesen und beide unterstützen eine begrenzte Anzahl von Neuschreibungszyklen. Wie bei SSDs ist der Zugriff auf Sektorebene des permanenten Speichers möglich, sollte dies für eine bestimmte Anwendung erforderlich sein.

Die unterschiedlichen Modelle verwenden verschiedene Arten von elektronischen Speichermedien, wie Intel 3D XPoint oder eine Kombination aus NAND-Flash und DRAM. Neue Arten von nicht-flüchtigen RAMs werden derzeit entwickelt. Verschiedene Anbieter und Modelle von NVDIMMs bieten unterschiedliche Eigenschaften für Leistung und Langlebigkeit.

Da sich die entsprechenden Speichertechnologien noch in der frühen Entwicklungsphase befinden, ist bei der Hardware verschiedener Anbieter möglicherweise mit unterschiedlichen Einschränkungen zu rechnen. Daher sind die folgenden Aussagen als Verallgemeinerungen zu betrachten.

Ein permanenter Speicher ist bis zu zehn mal langsamer als DRAM, doch in etwa tausend mal schneller als Flash-Speicher. Im Gegensatz zum Vorgang des Auslöschens und Neuschreibens des gesamten Sektors beim Flash-Speicher kann der permanente Speicher auf Byte-zu-Byte-Basis neu geschrieben werden. Da die Neuschreibungszyklen begrenzt sind, können permanente Speicher schließlich Millionen von Neuschreibungen verarbeiten, verglichen mit Tausenden von Zyklen des Flash-Speichers.

Das hat zwei erhebliche Folgen:

  • Beim aktuellen Stand der Technik ist es nicht möglich, ein System nur mit permanentem Speicher auszuführen und dadurch einen gänzlich nicht-flüchtigen Hauptspeicher zu erzielen. Sie müssen einen herkömmlichen RAM mit NVDIMMs kombinieren. Das Betriebssystem und die Anwendungen werden am herkömmlichen RAM ausgeführt und NVDIMMs bieten eine sehr schnelle ergänzende Speichermöglichkeit.

  • Aufgrund der Leistungsmerkmale der permanenten Speicher von verschiedenen Anbietern müssen Programmierer möglicherweise die Hardwarespezifikationen der NVDIMMs an einem bestimmten Server berücksichtigen, einschließlich deren Anzahl und belegten Speichersteckplätze. Dies wirkt sich offensichtlich auf die Verwendung des Hypervisors aus sowie auf die Migration von Software zwischen verschiedenen Host-Rechnern usw.

Dieses neue Speicher-Untersystem ist in Version 6 des ACPI-Standards definiert. libnvdimm unterstützt jedoch NVDIMMs, die den Standard noch nicht erfüllen, wodurch diese auf gleiche Weise verwendet werden können.

24.2 Begriffe

Region

Eine Region ist ein Block des permanenten Speichers, der in einen oder mehrere Namespaces unterteilt werden kann. Der Zugriff auf den permanenten Speicher einer Region ist erst nach dessen Zuordnung zu einem Namespace möglich.

Namespace

Ein einzelner zusammenhängend adressierter Bereich eines nicht-flüchtigen Speichers, vergleichbar mit NVM Express SSD-Namespaces oder SCSI Logical Units (LUNs). Namespaces werden im /dev-Verzeichnis des Servers als separate Blockgeräte angezeigt. Abhängig von der erforderlichen Zugriffsmethode können Namespaces entweder Speicherplatz von verschiedenen NVDIMMs in größere Volumes zusammenfassen oder dessen Partitionierung in kleinere Volumes zulassen.

Modus

Jeder Namespace weist einen Modus auf, der definiert, welche NVDIMM-Funktionen für diesen Namespace aktiviert sind. Gleichgeordnete Namespaces der selben übergeordneten Region sind im Typ immer gleich, werden jedoch möglicherweise mit verschiedenen Modi konfiguriert. Namespace-Modi:

raw

Speichermedium. Keine Unterstützung von DAX. Kompatibel mit anderen Betriebssystemen.

sector

Für veraltete Dateisysteme, die keine Checksumme für Metadaten erstellen. Geeignet für kleine Boot-Volumes. Kompatibel mit anderen Betriebssystemen.

fsdax

Dateisystem-DAX-Modus. Standardmodus, falls kein anderer Modus angegeben wird. Erstellt ein Blockgerät (/dev/pmemX [.Y]), das DAX für ext4 oder XFS unterstützt.

devdax

Geräte-DAX-Modus. Erstellt eine Einzelzeichen-Gerätedatei ( /dev/daxX.Y ). Die Erstellung eines Dateisystems ist nicht erforderlich.

Typ

Jeder Namespace und jede Region weist einen Typ auf, der definiert, auf welche Weise auf den permanenten Speicher, der mit diesem Namespace oder dieser Region verknüpft ist, zugegriffen wird. Ein Namespace hat immer denselben Typ wie dessen übergeordnete Region. Es gibt zwei verschiedene Typen: den permanenten Speicher und den Block-Modus.

Permanenter Speicher (PMEM)

Der PMEM-Speicher bietet Zugriff auf Byte-Ebene, genauso wie RAM. Hiermit wird der Direktzugriff (DAX) aktiviert. Der Zugriff auf den Speicher umgeht also den Seiten-Cache des Kernels und gelangt direkt zum Speichermedium. Mit PMEM kann zudem ein einzelner Namespace mehrere überlappende NVDIMMs enthalten und auf alle kann jeweils als Einzelgerät zugegriffen werden.

Block-Modus (BLK)

Der BLK-Zugriff erfolgt in Sektoren (meist 512 Byte) über ein definiertes Zugriffsfenster, die sogenannte Apertur. Dieses Verhalten entspricht eher einem herkömmlichen Festplattenlaufwerk. Dies bedeutet außerdem, dass sowohl Lese- als auch Schreibvorgänge im Kernel zwischengespeichert werden. Beim BLK-Zugriff erfolgt der Zugriff auf die einzelnen NVDIMM jeweils als separater Namespace.

Einige Geräte unterstützen sowohl den PMEM- als auch den BLK-Modus. Darüber hinaus kann in einigen Fällen auch der Speicher in separate Namespaces aufgeteilt werden, sodass der Zugriff auf einige Namespaces über PMEM, auf andere dagegen über BLK erfolgen kann.

Mit Ausnahme von devdax-Namespaces müssen alle Typen mit einem Dateisystem wie ext2, ext4 oder XFS formatiert werden, wie ein herkömmliches Laufwerk.

Direktzugriff (Direct Access, DAX)

Durch DAX kann ein permanenter Speicher direkt im Adressbereich eines Prozesses zugeordnet werden, beispielsweise über den Systemaufruf mmap. Dies ist ideal für den direkten Zugriff auf große PMEM-Mengen ohne zusätzliches RAM, zum Registrieren von PMEM-Blöcken für RDMA sowie für die direkte Zuweisung zu virtuellen Computern.

Physikalische DIMM-Adresse (DPA)

Eine Speicheradresse als Offset in den Speicher eines einzelnen DIMMs, das heißt beginnend bei Null als niedrigstem adressierbaren Byte in diesem DIMM.

Kennung

Im NVDIMM gespeicherte Metadaten wie beispielsweise Namespace-Definitionen. Der Zugriff ist über DSM möglich.

Gerätespezifische Methode (Device-specific method, DSM)

ACPI-Methode für den Zugriff auf die Firmware eines NVDIMM.

24.3 Anwendungsfälle

24.3.1 PMEM mit DAX

Es ist wichtig zu wissen, dass diese Art von Speicherzugriff keine Transaktion ist. Im Fall eines Stromausfalls oder eines anderen Systemfehlers werden die Daten möglicherweise nicht vollständig in den Speicher geschrieben. Ein PMEM-Speicher ist nur für Anwendungen geeignet, die teilweise geschriebene Daten verarbeiten können.

24.3.1.1 Anwendungen, die von einem großen Byte-adressierbaren Speicher profitieren.

Wenn am Server eine Anwendung gehostet wird, die direkt einen großen Teil eines schnellen Speichers Byte für Byte verwendet, kann der Programmierer mit dem Systemaufruf mmap Blöcke des permanenten Speichers direkt in den Adressbereich der Anwendung stellen, ohne auf zusätzlichen System-RAM zurückgreifen zu müssen.

24.3.1.2 Vermeiden des Kernel-Seiten-Cache

Wenn Sie den RAM für den Seiten-Cache aufsparen und den nicht-flüchtigen Speicher anderen Anwendungen zuweisen möchten. Dieser könnte beispielsweise zum Speichern von VM-Images vorgesehen werden. Diese Images würden nicht in den Cache gestellt werden, was die Cache-Auslastung am Host reduzieren und mehr VMs pro Host zulassen würde.

24.3.2 PMEM mit BTT

Diese Variante ist nützlich, wenn Sie den permanenten Speicher auf einigen NVDIMMs als einen Datenträger-ähnlichen Pool von sehr schnellen Speichern verwenden möchten.

Anwendungen halten diese Geräte für sehr schnelle SSDs, die wie jedes andere Speichergerät verwendet werden. LVM kann beispielsweise auf den nichtflüchtigen Speicher aufgesetzt werden und funktioniert normal.

BTT hat den Vorteil, dass die Unteilbarkeit beim Schreiben in den Sektor gewährleistet ist. Somit bleiben sogar sehr anspruchsvolle und von Datenintegrität abhängige Anwendungen funktionsfähig. Die Erstellung von Fehlerberichten funktioniert über standardmäßige Kanäle zur Fehlerberichterstellung.

24.3.3 BLK-Speicher

Dieser Speicher ist weniger anfällig gegenüber dem Ausfall einzelner Geräte, verursacht jedoch zusätzlichen Verwaltungsaufwand, da jedes NVDIMM als separates Gerät angezeigt wird. PMEM mit BTT ist daher im Allgemeinen vorzuziehen.

Anmerkung
Anmerkung

Der BLK-Speicher wird nicht mehr verwendet und in künftigen Versionen von SUSE Linux Enterprise Server nicht unterstützt.

24.4 Tools zur Verwaltung von permanenten Speichern

Zur Verwaltung eines permanenten Speichers muss das Paket ndctl installiert werden. Dadurch wird auch das Paket libndctl installiert. Es enthält einige Benutzerbereich-Bibliotheken zum Konfigurieren von NVDIMMs.

Diese Tools arbeiten mit der Bibliothek libnvdimm, die drei Typen von NVDIMMs unterstützt:

  • PMEM

  • BLK

  • PMEM und BLK gleichzeitig

Das ndctl-Dienstprogramm enthält einige nützliche man-Seiten, auf die mit dem folgenden Kommando zugegriffen wird:

ndctl help subcommand

Eine Liste der verfügbaren Unterkommandos erhalten Sie mit:

ndctl --list-cmds

Folgende Unterkommandos stehen zur Verfügung:

version

Zeigt die aktuelle Version der NVDIMM-Unterstützungstools an.

enable-namespace

Stellt den angegebenen Namespace zur Verfügung.

disable-namespace

Verhindert die Verwendung des angegebenen Namespace.

create-namespace

Erstellt einen neuen Namespace aus den angegebenen Speichergeräten.

destroy-namespace

Entfernt den angegebenen Namespace.

enable-region

Stellt die angegebene Region zur Verfügung.

disable-region

Verhindert die Verwendung der angegebenen Region.

zero-labels

Löscht die Metadaten von einem Gerät.

read-labels

Ruft die Metadaten vom angegebenen Gerät ab.

list

Zeigt verfügbare Geräte an.

help

Zeigt Informationen zur Verwendung des Tools an.

24.5 Einrichten eines permanenten Speichers

24.5.1 Anzeigen des verfügbaren NVDIMM-Speichers

Mit dem Kommando ndctl list werden alle verfügbaren NVDIMMs in einem System aufgelistet.

Im folgenden Beispiel hat das System drei NVDIMMs, die sich in einem einzelnen, dreikanaligen überlappenden Set befinden.

root # ndctl list --dimms

[
 {
  "dev":"nmem2",
  "id":"8089-00-0000-12325476"
 },
 {
  "dev":"nmem1",
  "id":"8089-00-0000-11325476"
 },
 {
  "dev":"nmem0",
  "id":"8089-00-0000-10325476"
 }
]

Mit einem anderen Parameter listet ndctl list auch die verfügbaren Regionen auf.

Anmerkung
Anmerkung

Regionen erscheinen möglicherweise nicht in numerischer Reihenfolge.

Beachten Sie, dass zwar nur drei NVDIMMs vorhanden sind, doch vier Regionen angezeigt werden.

root # ndctl list --regions

[
 {
  "dev":"region1",
  "size":68182605824,
  "available_size":68182605824,
  "type":"blk"
 },
 {
  "dev":"region3",
  "size":202937204736,
  "available_size":202937204736,
  "type":"pmem",
  "iset_id":5903239628671731251
  },
  {
   "dev":"region0",
   "size":68182605824,
   "available_size":68182605824,
   "type":"blk"
  },
  {
   "dev":"region2",
   "size":68182605824,
   "available_size":68182605824,
   "type":"blk"
  }
]

Der Speicherplatz ist auf zwei verschiedene Arten verfügbar: entweder als drei separate 64 GB-Regionen vom Typ BLK oder als eine kombinierte 189 GB-Region vom Typ PMEM, die den gesamten Speicherplatz auf den drei überlappenden NVDIMMs als ein einziges Volume darstellt.

Beachten Sie, dass der angezeigte Wert für available_size identisch ist mit dem Wert für size. Dies bedeutet, dass noch kein Speicherplatz zugeordnet wurde.

24.5.2 Konfigurieren des Speichers als einzelnen PMEM-Namespace mit DAX

Im ersten Beispiel konfigurieren wir unsere drei NVDIMMs in einem einzelnen PMEM-Namespace mit Direktzugriff (DAX).

Im ersten Schritt erstellen wir einen neuen Namespace.

root # ndctl create-namespace --type=pmem --mode=fsdax --map=memory
{
 "dev":"namespace3.0",
 "mode":"memory",
 "size":199764213760,
 "uuid":"dc8ebb84-c564-4248-9e8d-e18543c39b69",
 "blockdev":"pmem3"
}

Dadurch wird ein Blockgerät /dev/pmem3 erstellt, das DAX unterstützt. Die 3 im Gerätenamen wird von der Nummer der übergeordneten Region übernommen, in diesem Fall region3.

Die Option --map=memory reserviert einen Teil des PMEM-Speicherplatzes auf den NVDIMMs für die Zuordnung interner Kernel-Datenstrukturen namens struct pages. Dadurch kann der neue PMEM-Namespace mit Funktionen wie O_DIRECT I/O und RDMA verwendet werden.

Aufgrund der Reservierung eines Teils des permanenten Speichers für Kernel-Datenstrukturen hat der resultierende PMEM-Namespace eine geringere Kapazität als die übergeordnete PMEM-Region.

Als nächstes überprüfen wir, ob das neue Blockgerät für das Betriebssystem verfügbar ist:

root # fdisk -l /dev/pmem3
Disk /dev/pmem3: 186 GiB, 199764213760 bytes, 390164480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Bevor es verwendet werden kann, muss es wie jedes andere Gerät formatiert werden. In diesem Beispiel formatieren wir es mit XFS:

root # mkfs.xfs /dev/pmem3
meta-data=/dev/pmem3      isize=256    agcount=4, agsize=12192640 blks
         =                sectsz=4096  attr=2, projid32bit=1
         =                crc=0        finobt=0, sparse=0
data     =                bsize=4096   blocks=48770560, imaxpct=25
         =                sunit=0      swidth=0 blks
naming   =version 2       bsize=4096   ascii-ci=0 ftype=1
log      =internal log    bsize=4096   blocks=23813, version=2
         =                sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none            extsz=4096   blocks=0, rtextents=0

Danach können wir das neue Laufwerk in ein Verzeichnis einhängen:

root # mount -o dax /dev/pmem3 /mnt/pmem3

Dann überprüfen wir, ob wir nun über ein DAX-fähiges Gerät verfügen:

root # mount | grep dax
/dev/pmem3 on /mnt/pmem3 type xfs (rw,relatime,attr2,dax,inode64,noquota)

Das Ergebnis ist ein PMEM-Namespace, der mit dem XFS-Dateisystem formatiert und mit DAX eingehängt ist.

mmap()-Aufrufe von Dateien in diesem Dateisystem geben virtuelle Adressen zurück, die direkt dem permanenten Speicher auf unseren NVDIMMs zugeordnet werden. Der Seiten-Cache wird dabei voll umgangen.

fsync- oder msync-Aufrufe von Dateien in diesem Dateisystem stellen weiterhin sicher, dass geänderte Daten vollständig in die NVDIMMs geschrieben werden. Diese Aufrufe löschen die Zeilen des Prozessor-Cache, die mit Seiten verknüpft sind, die im Benutzerbereich über mmap-Zuordnungen geändert wurden.

24.5.2.1 Entfernen eines Namespace

Bevor wir einen anderen Volume-Typ erstellen, der den selben Speicher verwendet, müssen wir das PMEM-Volume aushängen und dann entfernen.

Hängen Sie es zunächst aus:

root # umount /mnt/pmem3

Deaktivieren Sie dann den Namespace:

root # ndctl disable-namespace namespace3.0
disabled 1 namespace

Löschen Sie es nun:

root # ndctl destroy-namespace namespace3.0
destroyed 1 namespace

24.5.3 Erstellen eines PMEM-Namespace mit BTT

Im nächsten Beispiel erstellen wir einen PMEM-Namespace, der BTT verwendet.

root # ndctl create-namespace --type=pmem --mode=sector
{
 "dev":"namespace3.0",
 "mode":"sector",
 "uuid":"51ab652d-7f20-44ea-b51d-5670454f8b9b",
 "sector_size":4096,
 "blockdev":"pmem3s"
}

Überprüfen Sie als nächstes, ob das Gerät vorhanden ist:

root # fdisk -l /dev/pmem3s
Disk /dev/pmem3s: 188.8 GiB, 202738135040 bytes, 49496615 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Wie der vorher konfigurierte DAX-fähige PMEM-Namespace verbraucht dieser BTT-fähige Namespace den gesamten verfügbaren Speicherplatz auf den NVDIMMs.

Anmerkung
Anmerkung

Das angehängte s am Ende des Gerätenamens (/dev/pmem3s) steht für sector. Damit lassen sich PMEM- und BLK-Namespaces, die zur Verwendung von BTT konfiguriert wurden, leicht unterscheiden.

Das Volume wird wie im vorigen Beispiel formatiert und eingehängt.

Der hier gezeigte PMEM-Namespace kann DAX nicht verwenden. Stattdessen verwendet er BTT für die Unteilbarkeit beim Schreiben des Sektors. Bei jedem Schreiben des Sektors über den PMEM-Blocktreiber ordnet BTT einen neuen Sektor zu, um neue Daten zu empfangen. BTT aktualisiert ungeteilt die internen Zuordnungsstrukturen, nachdem alle neuen Daten vollständig geschrieben sind, sodass die neu geschriebenen Daten den Anwendungen zur Verfügung stehen. Wenn zu irgendeinem Zeitpunkt dieses Vorgangs der Strom ausfällt, sind alle geschriebenen Daten verloren und die Anwendung hat Zugriff auf die alten Daten, die noch intakt sind. Dadurch wird der Zustand der sogenannten „zerrissenen Sektoren“ verhindert.

Dieser BTT-fähige PMEM-Namespace wird wie ein Dateisystem formatiert und verwendet, genau wie jedes andere Standard-Blockgerät. Die Verwendung mit DAX ist nicht möglich. mmap-Zuordnungen für Dateien auf diesem Blockgerät verwenden jedoch den Seiten-Cache.

Anmerkung
Anmerkung

In beiden Beispielen wird der Speicherplatz aus allen NVDIMMs in einem einzigen Volume kombiniert. Wenn ein Fehler bei einem einzelnen NVDIMM auftritt, geht daher möglicherweise der Inhalt des gesamten Volumes verloren, wie bei einem nicht redundanten Disk-Array. Je mehr NVDIMMs sich im Volume befinden, desto höher ist die Gefahr eines solchen Fehlers.

24.5.3.1 Entfernen des PMEM-Volumes

Wie im vorherigen Beispiel müssen zunächst das Volume und der Namespace entfernt werden, bevor der Speicherplatz neu zugewiesen werden kann:

root # ndctl disable-namespace namespace3.0
disabled 1 namespace

root # ndctl destroy-namespace namespace3.0
destroyed 1 namespace

24.5.4 Erstellen von BLK-Namespaces

In diesem Beispiel erstellen Sie drei separate BLK-Geräte, also je ein Gerät pro NVDIMM.

Diese Vorgehensweise bietet den Vorteil, dass die anderen Volumes nicht beeinträchtigt werden, wenn ein einzelnes NVDIMM ausfällt.

Anmerkung
Anmerkung

Die Befehle müssen für jeden Namespace wiederholt werden.

root # ndctl create-namespace --type=blk --mode=sector
{
 "dev":"namespace1.0",
 "mode":"sector",
 "uuid":"fed466bd-90f6-460b-ac81-ad1f08716602",
 "sector_size":4096,
 "blockdev":"ndblk1.0s"
}
   
root # ndctl create-namespace --type=blk --mode=sector
{
 "dev":"namespace0.0",
 "mode":"sector",
 "uuid":"12a29b6f-b951-4d08-8dbc-8dea1a2bb32d",
 "sector_size":4096,
 "blockdev":"ndblk0.0s"
}
    
root # ndctl create-namespace --type=blk --mode=sector
{
 "dev":"namespace2.0",
 "mode":"sector",
 "uuid":"7c84dab5-cc08-452a-b18d-53e430bf8833",
 "sector_size":4096,
 "blockdev":"ndblk2.0s"
}

Überprüfen Sie anschließend, ob die neuen Geräte vorhanden sind:

root # fdisk -l /dev/ndblk*
Disk /dev/ndblk0.0s: 63.4 GiB, 68115001344 bytes, 16629639 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ndblk1.0s: 63.4 GiB, 68115001344 bytes, 16629639 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ndblk2.0s: 63.4 GiB, 68115001344 bytes, 16629639 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Die für BLK-Namespaces erzeugten Blockgeräte erhalten den Namen /dev/ndblkX.Y, wobei X für die Nummer der übergeordneten Region steht und Y eine eindeutige Namespace-Nummer in dieser Region bezeichnet. /dev/ndblk2.0s ist also der untergeordnete Namespace Nr. 0 der Region 2.

Wie im vorherigen Beispiel bedeutet das angehängte s, dass dieser Namespace für BTT konfiguriert ist, also für den sektorbasierten Zugriff. Der Zugriff erfolgt über ein Blockfenster; die Programme können DAX daher nicht verwenden, doch die Zugriffe werden zwischengespeichert.

Alle Geräte müssen vor der Verwendung wie gewohnt formatiert und eingehängt werden.

24.6 Fehlerbehebung

Permanenter Speicher ist beständiger als SSD-Speicher, kann allerdings dennoch verschleißen. Wenn ein NVDIMM ausfällt, muss das einzelne Modul isoliert werden, in dem der Fehler aufgetreten ist, sodass die verbleibenden Daten wiederhergestellt werden können und die Hardware ausgetauscht werden kann. Drei Punkte sind festzustellen:

  1. Welches Modul ist ausgefallen (wo befindet sich der physische Standort des defekten Moduls)?

  2. Welcher namespace (/dev/pmemX) enthält nunmehr fehlerhafte Blöcke?

  3. Welche anderen Namespaces oder Regionen greifen ebenfalls auf das physische Modul zu?

Sobald Sie das fehlerhafte Modul und dazu die Namespaces und Regionen ausgemacht haben, die dieses Modul verwenden, können Sie die Daten in den anderen, nicht betroffenen Namespaces sichern, den Server herunterfahren und das NVDIMM austauschen.

24.6.1 Suche nach einem fehlerhaften Modul

Eine Gruppe von NVDIMMs befindet sich in DIMM-Steckplätzen auf der Hauptplatine des Servers.

Im entstehenden Speicherplatz legt das Betriebssystem mindestens einen Namespace an, z. B. region0.

Innerhalb dieser Regionen werden dann bestimmte Namespaces definiert, z. B. /dev/pmem1 oder /dev/dax0.

Eine einzelne Region mit Speicherplatz aus drei NVDIMMs wurde beispielsweise als drei Namespaces konfiguriert:

NVDIMM 0

region0

/dev/pmem1

 

NVDIMM 1

[X]

/dev/pmem2s

 

NVDIMM 2

/dev/dax0

 

In diesem Beispiel ist der mit einem [X] gekennzeichnete Teil in region0 beschädigt oder defekt.

Sie müssen wie folgt vorgehen:

  1. Stellen Sie fest, in welchem/welchen NVDIMM-Modul(en) sich die betroffene Region befindet.

    Dies ist insbesondere dann von Bedeutung, wenn die Region auf mehreren überlappenden NVDIMMs liegt.

  2. Sichern Sie den Inhalt aller anderen Namespaces auf dem betroffenen NVDIMM.

    In diesem Beispiel sichern Sie den Inhalt von /dev/pmem2s.

  3. Ermitteln Sie die Beziehung zwischen den Namespaces und der physischen Position des NVDIMM (Steckplatz auf der Hauptplatine).

    Der Server muss heruntergefahren werden, die Abdeckung ist abzunehmen und die defekten Module sind zu ermitteln, herauszunehmen und auszutauschen.

24.6.2 Testen des permanenten Speichers

Anmerkung
Anmerkung: Voraussetzungen für die Fehlersuche

Zum Testen ist das Kernel-Modul nfit_test erforderlich.

Das Testverfahren wird ausführlich auf der GitHub-Seite für den Befehl ndctl in Schritt 1–4 im Abschnitt Unit test (Gerätetest) beschrieben. Siehe Abschnitt 24.7, „Weiterführende Informationen“ am Ende dieses Kapitels.

Prozedur 24.1: Testverfahren
  1. Führen Sie den Befehl ndctl mit den Parametern list -RM aus.

    Die Liste der fehlerhaften Blöcke wird angezeigt.

     tux > sudo ndctl list -RM 
      :
      :
     { 
       "dev":"region5", 
       "size":33554432, 
       "available_size":33554432, 
       "type":"pmem", 
       "iset_id":4676476994879183020, 
       "badblock_count":8, 
       "badblocks":[ 
         { 
           "offset":32768, 
           "length":8, 
           "dimms":[ 
              "nmem1" 1  
           ] 
         } 
       ] 
     }, 
     :

    1

    Hier ist der betroffene NVDIMM ersichtlich.

  2. Führen Sie den Befehl ndctl mit den Parametern list -Du aus.

    Die Zugriffsnummer des DIMM wird angezeigt.

      tux > sudo ndctl list -Du
      { 
         "dev":"nmem1", 
         "id":"cdab-0a-07e0-feffffff", 
         "handle":"0x1", 1 
         "phys_id":"0x1"     
      }, 
       : 
       :

    1

    Dies ist die Zugriffsnummer des NVDIMM.

  3. Führen Sie den Befehl ndctl mit den Parametern list --d DIMM-Name aus.

     tux > sudo ndctl list -R -d nmem1 
     [ 
       { 
         "dev":"region5", 
         "size":33554432, 
         "available_size":33554432, 
         "type":"pmem", 
         "iset_id":4676476994879183020, 
         "badblock_count":8 
        }, 
       : 
       :

24.7 Weiterführende Informationen

Für weitere Informationen zu diesem Thema siehe die folgende Liste:

  • Permanenter Speicher – Wiki

    Enthält Anweisungen zum Konfigurieren von NVDIMM-Systemen, Informationen zu Tests sowie Links zu Spezifikationen für die Aktivierung von NVDIMMs. Diese Site wird im Zuge der NVDIMM-Unterstützung in Linux entwickelt.

  • Permanenter Speicher – Programmierung

    Informationen zum Konfigurieren, Verwenden und Programmieren von Systemen mit nicht-flüchtigem Speicher unter Linux und anderen Betriebssystemen. Behandelt die NVM-Bibliothek (NVML), die nützliche APIs zum Programmieren mit permanentem Speicher im Benutzerbereich bereitstellt.

  • LIBNVDIMM: Nicht-flüchtige Geräte

    Für Kernel-Entwickler gedacht und Teil des Dokumentationsordners im aktuellen Linux-Kernel-Baum. Es beschreibt die verschiedenen Kernel-Module, die an der NVDIMM-Aktivierung beteiligt sind, gibt einige technische Details zur Kernel-Implementierung und erläutert die sysfs-Schnittstelle zum Kernel, die vom ndctl-Tool verwendet wird.

  • GitHub: pmem/ndctl

    Dienstprogramm-Bibliothek zur Verwaltung des libnvdimm-Untersystems im Linux-Kernel. Enthält zudem Benutzerbereich-Bibliotheken sowie Einheitentests und eine Dokumentation.

Diese Seite drucken