4.11. Dateisysteme und Speicher (Maschinenübersetzung)

XFS unterstützt nun gemeinsame Datenerweiterungen beim Kopieren beim Schreiben

Das XFS-Dateisystem unterstützt die Funktionalität des gemeinsamen Kopierens beim Schreiben von Datenerweiterungen. Diese Funktion ermöglicht es zwei oder mehr Dateien, einen gemeinsamen Satz von Datenblöcken gemeinsam zu nutzen. Wenn sich eine der Dateien ändert, die gemeinsame Blöcke teilen, unterbricht XFS die Verknüpfung zu gemeinsamen Blöcken und erstellt eine neue Datei. Dies ist vergleichbar mit der Copy-on-Write (COW)-Funktionalität in anderen Dateisystemen.

Gemeinsame Copy-on-Write-Datenerweiterungen sind:

Schnell
Das Erstellen von gemeinsamen Kopien verwendet keine Festplatten-I/Os.
Platzsparend
Gemeinsame Blöcke verbrauchen keinen zusätzlichen Festplattenspeicher.
Transparent
Dateien, die gemeinsame Blöcke teilen, verhalten sich wie normale Dateien.

Userspace-Utilities können gemeinsame Copy-on-Write Datenerweiterungen verwenden für:

  • Effizientes Klonen von Dateien, z.B. mit dem cp --reflinkBefehl
  • Snapshots pro Datei

Diese Funktionalität wird auch von Kernel-Subsystemen wie Overlayfs und NFS für einen effizienteren Betrieb genutzt.

Gemeinsame Datenerweiterungen beim Kopieren beim Schreiben sind nun standardmäßig aktiviert, wenn ein XFS-Dateisystem erstellt wird, beginnend mit der xfsprogsPaketversion4.17.0-2.el8.

Beachten Sie, dass Direct Access (DAX)-Geräte derzeit XFS mit gemeinsamen Copy-on-Write Datenerweiterungen nicht unterstützen. Um ein XFS-Dateisystem ohne diese Funktion zu erstellen, verwenden Sie den folgenden Befehl:

# mkfs.xfs -m reflink=0 block-device

Red Hat Enterprise Linux 7 kann XFS-Dateisysteme mit gemeinsamen Copy-on-Write-Datenerweiterungen nur im schreibgeschützten Modus mounten.

(BZ#1494028)

Die maximale Größe des XFS-Dateisystems beträgt 1024 TiB

Die maximal unterstützte Größe eines XFS-Dateisystems wurde von 500 TiB auf 1024 TiB erhöht.

Dateisysteme mit mehr als 500 TiB erfordern dies:

  • die Metadaten-CRC-Funktion und die freie Inode-Baum-Funktion sind beide im Dateisystemformat aktiviert und
  • die Zuordnungsgruppengröße beträgt mindestens 512 GiB.

In RHEL 8 erstellt das mkfs.xfsDienstprogramm Dateisysteme, die diese Anforderungen standardmäßig erfüllen.

Ein kleineres Dateisystem, das diese Anforderungen nicht erfüllt, auf eine neue Größe von mehr als 500 TiB zu erweitern, wird nicht unterstützt.

(BZ#1563617)

VDO unterstützt nun alle Architekturen

Virtual Data Optimizer (VDO) ist nun auf allen von RHEL 8 unterstützten Architekturen verfügbar.

Die Liste der unterstützten Architekturen finden Sie unter Kapitel 2, Architekturen (Maschinenübersetzung).

(BZ#1534087)

Der BOOM Bootmanager vereinfacht die Erstellung von Boot-Einträgen

BOOM ist ein Bootmanager für Linux-Systeme, die Bootloader verwenden, die die BootLoader-Spezifikation für die Konfiguration des Boot-Eintrags unterstützen. Es ermöglicht eine flexible Boot-Konfiguration und vereinfacht die Erstellung neuer oder geänderter Boot-Einträge: z.B. um Snapshot-Images des mit LVM erstellten Systems zu starten.

BOOM ändert die bestehende Bootloader-Konfiguration nicht und fügt nur zusätzliche Einträge ein. Die bestehende Konfiguration wird beibehalten, und jede Distributionsintegration, wie Kernel-Installations- und Aktualisierungsskripte, funktioniert weiterhin wie bisher.

BOOM hat eine vereinfachte Befehlszeilenschnittstelle (CLI) und eine API, die die Erstellung von Boot-Einträgen erleichtert.

(BZ#1649582)

LUKS2 ist nun das Standardformat für die Verschlüsselung von Volumes

In RHEL 8 ersetzt das Format LUKS Version 2 (LUKS2) das alte Format LUKS (LUKS1). Das dm-cryptSubsystem und das cryptsetupTool verwenden nun LUKS2 als Standardformat für verschlüsselte Datenträger. LUKS2 bietet verschlüsselte Datenträger mit Metadatenredundanz und automatischer Wiederherstellung im Falle eines teilweisen Metadatenkorruptionsereignisses.

Aufgrund des internen flexiblen Layouts ist LUKS2 auch für zukünftige Funktionen geeignet. Es unterstützt die automatische Entriegelung durch das eingebaute generische Kernel-Keyrying-Token, libcryptsetupdas es Benutzern ermöglicht, LUKS2-Volumes mithilfe einer im Kernel-Keyrying-Retentionsdienst gespeicherten Passphrase zu entsperren.

Weitere bemerkenswerte Verbesserungen sind:

  • Die Einrichtung des geschützten Schlüssels unter Verwendung des verpackten Schlüsselverschlüsselungsschemas.
  • Einfachere Integration mit Policy-Based Decryption (Clevis).
  • Bis zu 32 Key-Slots - LUKS1 bietet nur 8 Key-Slots.

Weitere Informationen finden Sie auf den Seiten cryptsetup(8)und cryptsetup-reencrypt(8)in der Dokumentation.

(BZ#1564540)

NVMe/FC wird von Broadcom Emulex Fibre Channel Adaptern vollständig unterstützt

Der Transporttyp NVMe over Fibre Channel (NVMe/FC) wird nun im Initiator-Modus vollständig unterstützt, wenn er mit Broadcom Emulex Fibre Channel 32Gbit Adaptern verwendet wird.

NVMe over Fibre Channel ist ein zusätzlicher Fabric-Transporttyp für das Nonvolatile Memory Express (NVMe) Protokoll, zusätzlich zum Remote Direct Memory Access (RDMA) Protokoll, das zuvor in Red Hat Enterprise Linux eingeführt wurde.

Um NVMe/FC im lpfcTreiber zu aktivieren, bearbeiten Sie die /etc/modprobe.d/lpfc.confDatei und fügen Sie die folgende Option hinzu:

lpfc_enable_fc4_type=3

Andere Treiber lpfcbleiben in der Technologievorschau.

Zusätzliche Einschränkungen:

  • Multipath wird bei NVMe/FC nicht unterstützt.
  • NVMe-Clustering wird von NVMe/FC nicht unterstützt.
  • Derzeit unterstützt Red Hat Enterprise Linux nicht die gleichzeitige Verwendung von NVMe/FC und SCSI/FC an einem Initiatorport.
  • Das kernel-alt Paket unterstützt NVMe/FC nicht.
  • kdump wird von NVMe/FC nicht unterstützt.
  • Das Booten vom Storage Area Network (SAN) NVMe/FC wird nicht unterstützt.

(BZ#1649497)

Neuer overridesAbschnitt der DM-Multipath-Konfigurationsdatei

Die /etc/multipath.confDatei enthält nun einen overridesAbschnitt, in dem Sie einen Konfigurationswert für alle Ihre Geräte festlegen können. Diese Attribute werden von DM Multipath für alle Geräte verwendet, es sei denn, sie werden durch die Attribute überschrieben, die im multipathsAbschnitt der /etc/multipath.confDatei für Pfade angegeben sind, die das Gerät enthalten. Diese Funktionalität ersetzt den all_devsParameter des devicesAbschnitts der Konfigurationsdatei, der nicht mehr unterstützt wird.

(BZ#1643294)

Die Installation und das Booten von NVDIMM-Geräten wird nun unterstützt

Vor diesem Update wurden nichtflüchtige Dual Inline Memory Module (NVDIMM)-Geräte in jedem Modus vom Installateur ignoriert.

Mit diesem Update bieten Kernelverbesserungen zur Unterstützung von NVDIMM-Geräten verbesserte Systemleistungsmerkmale und verbesserten Dateisystemzugriff für schreibintensive Anwendungen wie Datenbank- oder Analyse-Workloads sowie reduzierten CPU-Overhead.

Dieses Update bietet Unterstützung für:

  • Verwendung von NVDIMM-Geräten für die Installation unter Verwendung des Befehls nvdimmKickstart und der Benutzeroberfläche, wodurch es möglich ist, NVDIMM-Geräte im Sektormodus zu installieren und zu starten und NVDIMM-Geräte während der Installation in den Sektormodus umzukonfigurieren.
  • Die Erweiterung der KickstartSkripte für Anaconda um Befehle zur Handhabung von NVDIMM-Geräten.
  • Die Fähigkeit vongrub2, efibootmgrund efivarSystemkomponenten, mit NVDIMM-Geräten umzugehen und von ihnen zu booten.

(BZ#1499442)

Die Erkennung von Randpfaden in DM-Multipath wurde verbessert

Der multipathdDienst unterstützt nun eine verbesserte Erkennung von Randpfaden. Dies hilft Mehrwegegeräten, Pfade zu vermeiden, die wahrscheinlich immer wieder ausfallen, und verbessert die Leistung. Randpfade sind Pfade mit persistenten, aber intermittierenden I/O-Fehlern.

Die folgenden Optionen im Verhalten der /etc/multipath.confDatei steuern Randpfade:

  • marginal_path_double_failed_time,
  • marginal_path_err_sample_time,
  • marginal_path_err_rate_thresholdund
  • marginal_path_err_recheck_gap_time.

DM Multipath deaktiviert einen Pfad und testet ihn mit wiederholten I/Os für die konfigurierte Abtastzeit if:

  • die aufgelisteten multipath.confOptionen sind eingestellt,
  • ein Pfad in der konfigurierten Zeit zweimal ausfällt, und
  • andere Pfade sind verfügbar.

Wenn der Pfad während dieses Tests mehr als die konfigurierte Fehlerrate aufweist, ignoriert DM Multipath ihn für die konfigurierte Gap-Zeit und testet ihn dann erneut, um zu sehen, ob er gut genug funktioniert, um wiederhergestellt zu werden.

Weitere Informationen finden Sie in der multipath.confMan Page.

(BZ#1643550)

Standardverhalten für mehrere Warteschlangen

Blockgeräte verwenden nun die Multiqueue-Planung in Red Hat Enterprise Linux 8. Dies ermöglicht eine gute Skalierung der Blocklayer-Performance mit schnellen Solid-State-Laufwerken (SSDs) und Multicore-Systemen.

Der SCSI Multiqueue (scsi-mq) Treiber ist nun standardmäßig aktiviert, und der Kernel bootet mit der scsi_mod.use_blk_mq=YOption. Diese Änderung steht im Einklang mit dem vorgelagerten Linux-Kernel.

Device Mapper Multipath (DM Multipath) erfordert, dass der scsi-mqTreiber aktiv ist.

(BZ#1647612)

Stratis ist jetzt verfügbar

Stratis ist ein neuer lokaler Speichermanager. Es bietet verwaltete Dateisysteme auf Basis von Speicherpools mit zusätzlichen Funktionen für den Benutzer.

Mit Stratis können Sie Speicheraufgaben wie:

  • Verwaltung von Snapshots und Thin Provisioning
  • Automatische Vergrößerung der Dateisystemgrößen bei Bedarf
  • Dateisysteme pflegen

Um den Stratis-Speicher zu verwalten, verwenden Sie das stratisDienstprogramm, das mit dem stratisdHintergrunddienst kommuniziert.

Weitere Informationen finden Sie in der Dokumentation Stratis: Managing layered local storage with Stratis.

(JIRA:RHELPLAN-1212)