Data Domain: DDFS-FEHLER: dmbt_update_entry_nolock

Sammendrag: In diesem Artikel wird beschrieben, wie Sie das Problem beheben und das Dateisystem erneut aktivieren können, wenn das Data Domain File System (DDFS) mit der folgenden PANIC-Zeichenfolge einen Fehler aufweist: PANIC: ddr/dm/dmbt_iface.c: dmbt_update_entry_nolock ...

Denne artikkelen gjelder for Denne artikkelen gjelder ikke for Denne artikkelen er ikke knyttet til noe bestemt produkt. Det er ikke produktversjonene som identifiseres i denne artikkelen.
Ta en titt på andre ressurser

Symptomer

Die betroffene Data Domain (DD) meldet einen Fehler mit der folgenden Meldung für Systeme mit aktivierter ARL (Automatic Retention Lock) MTrees, die für die Replikation verwendet werden:

PANIC: ddr/dm/dmbt_iface.c: dmbt_update_entry_nolock
 
Betroffene Systeme:
  • PowerProtect Data Domains mit aktivierter ARL (Automatic Retention Lock).
 
Symptome:
  • Absturz des Data Domain-Dateisystems
  • Systeminstabilität 
  • Protokolle, die die obige Fehlermeldung unmittelbar vor einem Systemabsturz anzeigen

Årsak

Dieses Problem tritt auf, wenn ein MTree-Replikations-Snapshot zwischen den offenen und geschlossenen DDBOOST-Aufrufen auftritt.

Das Problem wird unter den folgenden Bedingungen ausgelöst:
  • Bei der nfsproc3_ddcp_open_file_3_svc() identifiziert eine Retention Lock (RL)-Datei, die innerhalb der ARL-Cool-off-Periode (COP) geändert wird, und setzt den Tag-Wert auf 0 (DM_TAG_DEFAULT) enthalten.
  • Die anschließende nfsproc3_ddcp_close_file_3_svc() Normalerweise setzt die Funktion das Tag auf einen gültigen Wert zurück.
  • Wenn jedoch eine Datei mit einem erweiterten Attribut erstellt und innerhalb des ARL-COP geändert wird und ein Snapshot zwischen den DDBOOST-Öffnungs- und Schließaufrufen auftritt, kann diese Sequenz den PANIC-Fehler auslösen.
 

Dies tritt bei 7.7.x und 7.10.x auf und der Auslöser ist, wenn Retention Lock (in der Regel ARL) auf den MTrees aktiviert ist.

Hinweis: Nur auf der Ziel-DD tritt ein Fehler auf – die Quell-DD sollte davon nicht betroffen sein.

Oppløsning

Gehen Sie wie folgt vor, um dieses Problem zu beheben: 

1. Unterbrechen Sie jeden Replikationskontext des ursprünglichen Quell- und Ziel-MTree.

2. Fastcopy der problematische MTree auf der Quell-DD
  • Dadurch wird eine neue, saubere Kopie des MTree ohne den problematischen Kontext erstellt.
3. Aktivieren Sie nicht die automatische Aufbewahrungssperre (ARL) auf dem neuen "fastcopied" MTree.
  • Dadurch wird verhindert, dass das Problem erneut auftritt.

4. Umleiten von Backups auf den neu schnell kopierten MTree auf Source the DD.
(Aktualisieren Sie alle Backupjobs so, dass sie auf den neuen MTree abzielen.)

5. Erstellen Sie einen neuen Replikationskontext zwischen dem neu fastkopierten MTree und der Ziel-DD.
  • Stellen Sie sicher, dass die neue Replikationseinrichtung vollständig synchronisiert ist.
  • Lassen Sie diese MTree-ARL deaktiviert, um zu verhindern, dass die PANIK erneut auftritt. 
    • Verwalten Sie die alten MTrees:
    • Belassen Sie die ursprünglichen MTrees vorerst auf den Quell- und Zielsystemen.
      • Nachdem die neue Replikation synchronisiert wurde und die Aufbewahrungsfrist für die alten MTree-Dateien abgelaufen ist, löschen Sie die Dateien in den alten MTrees.
      • Löschen Sie dann den alten MTree auf der Quelle und dem Ziel.

Tilleggsinformasjon

  • Es ist wichtig, das System nach der Durchführung der oben genannten Schritte auf weitere Anomalien zu überwachen.
  • Stellen Sie sicher, dass alle Backup-Policies und Replikationskontexte korrekt aktualisiert werden, um die Änderungen widerzuspiegeln.

Berørte produkter

Data Domain, Data Domain, Data Domain Retention Lock, DD OS 7.7
Artikkelegenskaper
Artikkelnummer: 000227777
Artikkeltype: Solution
Sist endret: 17 sep. 2026
Versjon:  6
Få svar på spørsmålene dine fra andre Dell-brukere
Støttetjenester
Sjekk om enheten din er dekket av støttetjenestene.