memory/patterns/ceph-dead-nvme-resurrection.md

PAT-014 — Dead-NVMe-Resurrection für Ceph-OSD

Trigger

Ceph-OSD auf externem/non-Corosync-Host startet nicht: KernelDevice errno-5 I/O-Errors beim Label-Lesen, Symlink /var/lib/ceph/osd/ceph-*/block ins Leere, VG „verschwindet".

Root Cause

NVMe-Controller im PCIe-Fabric gestorben (state=dead, Namespace 0B) — NICHT das Medium selbst. Nach PCI-reset kehrt der Controller oft unter NEUER Nummer zurück (nvme0 → nvme2!), alte Device-Mapper-Tabelle bleibt stale.

Resurrection-Sequence (verifizierte Reihenfolge)

1. Korrekte PCI-Addr finden: über sysfs-Pfad des Namespaces (/sys/class/block/nvmeXnY/device), NICHT raten — erster Versuch traf den falschen (gesunden!) Controller.
2. echo 1 > /sys/bus/pci/devices/<ADDR>/remove && echo 1 > /sys/bus/pci/rescan → Controller kommt als neue Instanz zurück, Namespaces wieder da.
3. pvscan --cache → VG/LV wieder sichtbar.
4. Stale DM-Table: lvchange -an <vg>/<lv> && lvchange -ay -K <vg>/<lv>
5. Lesetest: dd if=/dev/<vg>/<lv> bs=4M count=8 of=/dev/null — bei weiteren errno-5: NAND/Media defekt → OSD out lassen, Drive tauschen.
6. Permissions-Falle nach lvchange: udev setzt Owner root → chown ceph:ceph /dev/mapper/<dm-name>; chmod 660 (sonst bdev open: (13) Permission denied).
7. systemctl reset-failed ceph-osd@<id> && systemctl start ceph-osd@<id>
8. ceph osd in osd.<id> + Weight restaurieren.

Begleitregeln

• Klein/niedergewichtetes OSD niemals mit Weight 1.0 reintegrieren, solange Pools an Full-Ratios kratzen → sonst backfillfull/backfill_toofull-Blockade (Fall osd.3: re-in@1.0 → 96 % voll instant → 13 PGs blocked; Fix: crush reweight osd.3 0.05).
• Externe Non-Corosync-Hosts in /etc/hosts ALLER PVE-Nodes pflegen (GUI-500 „hostname lookup failed"), oder echter DNS-Record.

Verified

2026-09-30: osd.2 revived (Kingston SFYRDK2000G, PCI 03:00.0, → nvme2), 495 GiB, Weight 1.0; Cluster 17/17 up/in; Degraded 0,78 % fallend. osd.3 stabilized @ weight 0.05.

Smart-Log-Abgleich 2026-09-30 (korrigiert frühere Alters-These)

Kingston SFYRDK2000G (nvme0n2, trägt osd.2): percentage_used 6 %, media_errors 0, available_spare 100 %, unsafe_shutdowns 2, power_on_hours 1469, power_cycles 3. Geschwisterplatte nvme1n1 identisches Profil (6 % wear, 0 media errors). ⇒ Drive ist MEDIZINISCH GESUND — der Vorfall war rein Controller-(PCI)-Ebene, kein Media-Verschleiß. Kein Austausch nötig. Einziges Beobachtungsfeld: Temperatur 70 °C / Sensor2 78 °C (thermisches Throttling T1 3× aktiviert) — Kühlung prüfen wäre sinnvoll, aber keine Akutgefahr.