Data Domain : BoostFS présente un fonctionnement inattendu ou le point de montage ne répond plus

Symptômes :

• BoostFS se bloque et fonctionne de manière aléatoire. Cela se produit lorsque la charge applicative est élevée.
• L’application de sauvegarde exécute des READ et WRITE sur le point de montage BoostFS.
• Lorsqu’il y a des retards dans READ et WRITE à partir de l’application de sauvegarde, les logs BoostFS l’affichent error 5057 File handle is stale from Data Domain server.

Logs BoostFS :

###### 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)

Triage :

1. Recherchez l’erreur signalée ci-dessus dans les logs BoostFS et DDFS côté serveur.
2. Observez le délai dans READ et WRITE à partir de l’application de sauvegarde. Tenez compte des logs d’entrée et de sortie de l’API BoostFS.
3. Vérifiez la valeur définie pour OST_ABANDON_TIMEOUT (trois heures par défaut).
4. Vérifiez que le délai d’expiration du RPC est supérieur à la valeur définie pour OST_ABANDON_TIMEOUT.

1. Le problème est dû à un retard READ et WRITE par l’application de sauvegarde. Cela déclenche l’expiration du délai d’expiration du DDFS. Cela entraîne la fermeture du descripteur de fichier correspondant au bout de trois heures (valeur par défaut)
2. Il s’agit du délai d’expiration de suppression par défaut utilisé par DDFS pour identifier les descripteurs de fichiers inactifs. Les nouvelles écritures peuvent éventuellement rencontrer un fonctionnement inattendu côté client.

Contactez le support Dell pour augmenter le délai d’expiration qui nécessite un accès au bash.

Modifiez le paramètre OST_ABANDON_TIMEOUT côté serveur en suivant les étapes ci-dessous. Sa valeur peut être étendue à un maximum de 12 heures.

1. Connectez-vous au Data Domain avec l’accès du rôle d’administrateur . Le support passe en mode bash, puis entre en mode se mode avec ddsh -s
2. Vérifier l’original OST_ABANDON_TIMEOUT Valeur.

SE@dd## se sysparam show OST_ABANDON_TIMEOUT

3. Augmentez le OST_ABANDON_TIMEOUT Valeur. Par défaut, la valeur est 10800 (trois heures).

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. Redémarrez le système de fichiers après la modification du paramètre ci-dessus. Vérifiez auprès du client si ce redémarrage est autorisé. Si ce n’est pas le cas, planifiez une période de maintenance pour exécuter la commande suivante :

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