Fehlerbehebung bei NVMe-Laufwerken


In diesem Dokument werden Fehler aufgeführt, die bei der Verwendung von Laufwerken mit der NVMe-Schnittstelle (Persistent Express) auftreten können.

Sie können die NVMe-Schnittstelle für lokale SSDs und nichtflüchtige Speicher (Persistent Disk oder Google Cloud Hyperdisk) verwenden. Nur die neuesten Maschinenserien wie Tau T2A, M3, C3, C3D und H3 verwenden die NVMe für Persistent Disk. Confidential VMs verwenden auch NVMe for Persistent Disk. Alle anderen Compute Engine-Maschinen verwenden die SCSI-Laufwerksschnittstelle für nichtflüchtige Speicher.

E/A-Vorgangszeitüberschreitungsfehler

Wenn E/A-Zeitüberschreitungsfehler auftreten, kann die Latenz den Standardzeitüberschreitungsparameter für E/A-Vorgänge überschreiten, die an NVMe-Geräte gesendet werden.

Fehlermeldung:

[1369407.045521] nvme nvme0: I/O 252 QID 2 timeout, aborting
[1369407.050941] nvme nvme0: I/O 253 QID 2 timeout, aborting
[1369407.056354] nvme nvme0: I/O 254 QID 2 timeout, aborting
[1369407.061766] nvme nvme0: I/O 255 QID 2 timeout, aborting
[1369407.067168] nvme nvme0: I/O 256 QID 2 timeout, aborting
[1369407.072583] nvme nvme0: I/O 257 QID 2 timeout, aborting
[1369407.077987] nvme nvme0: I/O 258 QID 2 timeout, aborting
[1369407.083395] nvme nvme0: I/O 259 QID 2 timeout, aborting
[1369407.088802] nvme nvme0: I/O 260 QID 2 timeout, aborting
...

Lösung:

Erhöhen Sie den Wert des Zeitüberschreitungsparameters, um dieses Problem zu beheben.

  1. Rufen Sie den aktuellen Wert des Zeitüberschreitungsparameters auf.

    1. Bestimmen Sie, welcher NVMe-Controller vom nichtflüchtigen Speicher oder der lokalen SSD verwendet wird.
      ls -l /dev/disk/by-id
      
    2. Rufen Sie die in Sekunden angegebene Einstellung io_timeout für das Laufwerk auf.

      cat /sys/class/nvme/CONTROLLER_ID/NAMESPACE/queue/io_timeout
      
      Ersetzen Sie Folgendes:

      • CONTROLLER_ID: die ID des NVMe-Disk-Controllers, z. B. nvme1
      • NAMESPACE: der Namespace des NVMe-Laufwerks, z. B. nvme1n1

      Wenn Sie nur ein einzelnes Laufwerk haben, das NVMe verwendet, verwenden Sie den folgenden Befehl:

      cat /sys/class/nvme/nvme0/nvme0n1/queue/io_timeout
      

  2. Um den Zeitüberschreitungsparameter für E/A-Vorgänge zu erhöhen, die an NVMe-Geräte gesendet wurden, fügen Sie der Datei /lib/udev/rules.d/65-gce-disk-naming.rules die folgende Zeile hinzu und starten Sie dann die VM neu:

    KERNEL=="nvme*n*", ENV{DEVTYPE}=="disk", ATTRS{model}=="nvme_card-pd", ATTR{queue/io_timeout}="4294967295"
    

Getrennte Laufwerke werden weiterhin im Betriebssystem einer Compute-Instanz angezeigt

Auf VMs, die die Linux-Kernel-Version 6.0 bis 6.2 verwenden, funktionieren Vorgänge, bei denen die Compute Engine API-Methode instances.detachDisk oder der Befehl gcloud compute instances detach-disk verwendet wird, möglicherweise nicht wie erwartet. In der Google Cloud Console wird das Gerät als entfernt angezeigt, die Metadaten der Compute-Instanz (compute disks describe-Befehl) zeigen das Gerät als entfernt an, aber der Gerätebereitstellungspunkt und alle von udev-Regeln erstellten Symlinks sind weiterhin sichtbar in Gastbetriebssystem.

Fehlermeldung:

Der Versuch, vom getrennten Laufwerk auf der VM zu lesen, führt zu E/A-Fehlern:

sudo head /dev/nvme0n3

head: error reading '/dev/nvme0n3': Input/output error

Problem:

Betriebssystem-Images, die einen Linux 6.0-6.2-Kernel verwenden, aber keinen Backport einer NVMe-Fehlerbehebung enthalten, werden nicht erkannt, wenn ein NVMe-Laufwerk getrennt wird.

Lösung:

Starten Sie die VM neu, um das Entfernen des Laufwerks abzuschließen.

Verwenden Sie ein Betriebssystem mit einer Linux-Kernel-Version, bei der dieses Problem nicht auftritt, um dieses Problem zu vermeiden:

  • 5.19 oder älter
  • 6.3 oder höher

Mit dem Befehl uname -r im Gastbetriebssystem können Sie die Linux-Kernel-Version aufrufen.

Wenn Sie lokale SSD-Laufwerke an eine C3- oder C3D-VM anhängen, müssen Sie möglicherweise zusätzliche Schritte ausführen, um die Symlinks für die lokalen SSD-Laufwerke zu erstellen. Diese Schritte sind nur erforderlich, wenn Sie eines der folgenden von Google Cloud angebotenen öffentlichen Images verwenden:

  • SLES 15 SP4 und SP5
  • SLES 12 SP4

Diese zusätzlichen Schritte gelten nur für lokale SSD-Laufwerke. Für Persistent Disk-Volumes müssen Sie nichts tun.

Die zuvor aufgeführten öffentlichen Linux-Images haben nicht die richtige udev-Konfiguration, um Symlinks für lokale SSD-Geräte zu erstellen, die an C3- und C3D-VMs angehängt sind. Benutzerdefinierte Images enthalten möglicherweise auch nicht die erforderlichen udev-Regeln, die zum Erstellen von Symlinks für lokale SSD-Geräte erforderlich sind, die an C3- und C3D-VMs angehängt sind.

Verwenden Sie diese Anleitung, um udev-Regeln für SUSE- oder benutzerdefinierte Images hinzuzufügen.

  1. Suchen Sie das udev-Regelverzeichnis. Dies ist normalerweise /lib/udev/rules.d oder /usr/lib/udev/rules.d. Ihr Image hat möglicherweise ein anderes udev-Regelverzeichnis.
  2. Suchen Sie im udev-Regelverzeichnis die Datei 65-gce-disk-naming.rules.
  3. Wenn die Datei 65-gce-disk-naming.rules die folgende Zeile enthält, unterstützt Ihr Image die neuen Regeln und Sie können den Vorgang hier beenden:

    KERNEL=="nvme*n*", ATTRS{model}=="nvme_card[0-9]*",IMPORT{program}="google_nvme_id -d $tempnode"
    
  4. Wenn die vorherige Zeile oder die Datei 65-gce-disk-naming.rules nicht vorhanden ist, ersetzen Sie die vorhandene Datei oder erstellen Sie eine neue Datei mit dem Dateiinhalt von dieser URL: https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/rules.d/65-gce-disk-naming.rules Diese Datei enthält den aktualisierten Inhalt der Datei 65-gce-disk-naming.rules, einschließlich der Zeile aus dem vorherigen Schritt und anderer Regeln, die für die Benennung von Compute Engine-Laufwerken erforderlich sind. Beispiel:

    sudo curl -o 65-gce-disk-naming.rules https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/rules.d/65-gce-disk-naming.rules
    
  5. Wechseln Sie in das Verzeichnis udev.

  6. Suchen Sie im Verzeichnis udev die Datei google_nvme_id.

  7. Ersetzen Sie den Inhalt der vorhandenen Datei google_nvme_id oder erstellen Sie eine neue Datei mit dem Inhalt unter dieser URL:

    sudo curl -o google_nvme_id https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/google_nvme_id
    
  8. Achten Sie darauf, dass die Datei google_nvme_id ausführbar ist.

    sudo chmod 755 google_nvme_id
    
  9. Starten Sie die VM neu.

  10. Prüfen Sie, ob die Symlinks erfolgreich erstellt wurden.

    ls -l /dev/disk/by-id/google-local-nvme-ssd*
    

    Die Ausgabe sollte die gleiche Anzahl von Links auflisten wie lokale SSDs, die mit der Instanz verbunden sind, und jeder Link sollte auf einen anderen /dev/nvme-Gerätepfad verweisen. Beispiel:

    lrwxrwxrwx 1 root root 13 Jul 19 22:52 /dev/disk/by-id/google-local-nvme-ssd-0 -> ../../nvme0n1
    lrwxrwxrwx 1 root root 13 Jul 19 22:52 /dev/disk/by-id/google-local-nvme-ssd-1 -> ../../nvme1n1
    

    Weitere Informationen zu Gerätenamen finden Sie unter Gerätenamen.

    Führen Sie lsblk aus, um zu prüfen, ob die /dev/nvme-Gerätepfade lokale SSD-Geräte sind. NVMe-Geräte mit der Größe 375G sind lokale SSD-Geräte.

Nächste Schritte