Data Domain: BoostFS-Fehler oder Mount-Punkt reagiert nicht mehr

Symptome:

• BoostFS stürzt ab, und es tritt ein Fehler auf. Dies geschieht, wenn die Arbeitsbelastung hoch ist.
• Die Backupanwendung führt die Backupanwendung verzögert aus READ und WRITE Vorgänge auf dem BoostFS-Einhängepunkt.
• Bei Verzögerungen bei der READ und WRITE Vorgänge aus der Backupanwendung zeigen die BoostFS-Protokolle dies an error 5057 File handle is stale from Data Domain server.

BoostFS-Protokolle:

###### WRITE operation FAILED due to STALE FILE HANDLE error ######
Sep 11 00:36:29.635 7884 10740 [E] [ddp log] [1ECC:29F4] ddcl_ddcp_send_file_loop: Call to recv
refs2 failed. [ERR=5057] Sep 11 00:36:29.635 7884 10740 [E] [ddp log] [1ECC:29F4] ddcl_ddcp_pwrite: Call to send file loop2 failed. [ERR=5057]
Sep 11 00:36:29.635 7884 10740 [E] [ddp log] [1ECC:29F4] ddcl_ddcp_pwrite: Error in ddcl ddcp
pwrite. [ERR=5057] Sep 11 00:36:29.635 7884 10740 [E] [ddp log] [1ECC:29F4] ddp_write() failed Offset 11010048, BytesToWrite 1048576, BytesWritten 0 Err: 5057-File handle is stale
Sep 11 00:36:29.635 7884 10740 [E] bfs_cache_flush: failed: 5057 File handle is stale (0 bytes written)
Sep 11 00:36:29.651 7884 11292 [E] [ddp log] [1ECC:2C1C] ddcl_ddcp_send_file_loop: Call to recv
refs2 failed. [ERR=5057]
####### PANIC occurred HERE #######
Sep 11 00:36:29.667 7884 11292 [E] [ddp log] [1ECC:2C1C] PANIC: ..\ddcl\ddcl_ddcp.c:
ddcl_ddcp_commit: 4541: !(c->send_offset == c->write_offset)

Selektierung:

1. Überprüfen Sie die BoostFS- und serverseitigen DDFS-Protokolle auf den oben gemeldeten Fehler.
2. Beachten Sie die Verzögerung in READ und WRITE Vorgänge aus der Backupanwendung. Beachten Sie BoostFS-API-Eingangs- und -Beendigungsprotokolle.
3. Überprüfen Sie den für OST_ABANDON_TIMEOUT (Standardeinstellung drei Stunden).
4. Überprüfen Sie, ob das Timeout des RPC größer ist als der für OST_ABANDON_TIMEOUT.

1. Das Problem ist auf eine Verzögerung bei der READ und WRITE Vorgänge durch die Backupanwendung. Dies löst aus, dass das DDFS das Timeout verwirft. Dies führt zum Schließen des entsprechenden Datei-Handles nach drei Stunden (Standardwert)
2. Dies ist der standardmäßige Timeout-Zeitraum, der vom DDFS verwendet wird, um inaktive Dateihandles zu identifizieren. Schließlich kann es bei neuen Schreibvorgängen zu einer Panik auf der Clientseite kommen.

Wenden Sie sich an den Dell Support , um das Timeout zu erhöhen, für das Zugriff auf Bash erforderlich ist.

Ändern Sie die OST_ABANDON_TIMEOUT Parameter auf der Serverseite mithilfe der folgenden Schritte übergeben. Der Wert kann auf einen größeren Wert mit maximal 12 Stunden festgelegt werden.

1. Melden Sie sich bei Data Domain mit der Administratorrolle an. Der Support wechselt in den Bash-Modus und wechselt dann in den se Modus mit ddsh -s
2. Überprüfen Sie das Original OST_ABANDON_TIMEOUT Wert.

SE@dd## se sysparam show OST_ABANDON_TIMEOUT

3. Erhöhen Sie die OST_ABANDON_TIMEOUT Wert. Der Standardwert ist 10800 (drei Stunden).

SE@dd## se sysparam set OST_ABANDON_TIMEOUT=129600
SE@dd## se sysparam show OST_ABANDON_TIMEOUT

Name Description Current Default Override
------------------- --------------------------------- ------- ------- -----
---
OST_ABANDON_TIMEOUT DDCP abandon context timeout(sec) 129600 10800 rpc
------------------- --------------------------------- ------- ------- -----
---

SE@dd##priv set admin

4. Starten Sie das Dateisystem nach der obigen Parameteränderung neu. Lassen Sie sich vom Kunden bestätigen, ob dieser Neustart zulässig ist. Falls nicht, planen Sie einen Wartungszeitraum, um den folgenden Befehl auszuführen:

SE@dd## filesys disable
SE@dd## filesys enable