24 Permanenter Speicher #

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.

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.

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

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

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

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.

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.

root # umount /mnt/pmem3

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

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

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

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

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.

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

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

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

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.

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:

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

Sie müssen wie folgt vorgehen:

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.