Data Domain : un redémarrage inattendu de DDFS (Data Domain File System) s’est produit avec l’alerte EVT-FILESYS-00008/FILESYS-00008 ou EVT-FILESYS-00010/FILESYS-00010 ou EVT-FILESYS-00011/FILESYS-00011

Summary: Cet article de la base de connaissances explique ce qui se passe lorsqu’un redémarrage inattendu du système de fichiers se produit, les alertes potentielles rencontrées et les informations à saisir à des fins de triage. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms



Le processus DDFS est le principal processus responsable du fonctionnement du système de fichiers de déduplication DDOS (Data Domain Operating System).

Si ce processus rencontre un problème l’une des alertes suivantes est créée :
  • EVT-FILESYS-00008 / FILESYS-00008
  • EVT-FILESYS-00010 / FILESYS-00010
  • EVT-FILESYS-00011 / FILESYS-00011
Les alertes ci-dessus indiquent que le problème rencontré était inattendu et que des informations supplémentaires sont nécessaires pour en déterminer la cause.

L’alerte est envoyée via le mécanisme d’alerte configuré sur le système Data Domain, c’est-à-dire via e-mail/SNMP. L’alerte s’affiche également dans la sortie « alerts show history ».

Cause

Ce processus peut redémarrer de plusieurs manières, par exemple :
  • Une panique directe, c’est-à-dire un bogue de code explicite.
  • Un délai d’expiration interne est détecté. DDFS dispose d’un thread de surveillance des pulsations interne (appelé hmon) qui surveille l’intégrité des différents sous-systèmes du processus DDFS. Si hmon constate qu’un sous-système est suspendu ou a attendu trop longtemps, il met fin au processus DDFS.
  • Un délai d’expiration externe est détecté. Un processus appelé ddr_stated est responsable de la surveillance externe du processus DDFS grâce à un mécanisme de pulsations. Si DDFS n’envoie pas de pulsation à ddr_stated pendant une certaine durée, ddr_stated suppose que le DDFS est suspendu et met fin au processus DDFS.
  • Le processus demande une quantité de mémoire supérieure à celle autorisée.
  • Un contrôle d’intégrité interne a échoué.
Si l’une de ces conditions est validée, le système de fichiers tente de redémarrer automatiquement pour reprendre son fonctionnement normal. 

Pendant le redémarrage du DDFS, toutes les opérations en cours, telles que les restaurations/sauvegardes, c’est-à-dire les lectures/écritures, seront interrompues et devront être relancées. La plupart des applications de sauvegarde peuvent reconnaître que les lectures/écritures ont été interrompues et redémarrer ces opérations automatiquement.

En cas de redémarrage inattendu de DDFS, les événements suivants se produisent :
  • Le processus est arrêté.
  • L’empreinte mémoire utilisée par le processus est écrite dans un « fichier noyau » qui sera écrit dans un appareil de vidage principal, qui est une zone spéciale sur l’un des disques de l’unité principale. Un fichier noyau contient les informations nécessaires pour déboguer la cause du redémarrage inattendu.
  • Une fois que l’étape ci-dessus est terminée, le processus DDFS peut redémarrer.
  • En parallèle, c’est-à-dire une fois que le DDFS est en cours de redémarrage, le fichier noyau doit être extrait de l’appareil de vidage principal vers un système de fichiers DDOS pour pouvoir y accéder. Le processus qui réalise cette tâche est appelé « savecore ».
  • Savecore crée un répertoire temporaire initial dans /ddvar/core. Le répertoire s’appelle « app-<date and time the core file occurred> ».
  • Étant donné que DDFS utilise la majorité de la mémoire du système, l’empreinte de la mémoire du DDFS peut être élevée. Pour réduire la quantité de données écrites dans le fichier noyau, savecore lit depuis l’appareil de vidage principal, passe ces informations par gzip, pour s’assurer que le fichier noyau est aussi petit que possible, et commence à écrire dans un fichier appelé « core-incomplete.gz ».
  • Une fois ce processus terminé, le répertoire temporaire est supprimé, le fichier noyau est placé dans /ddvar/core et est renommé. La convention d’affectation de noms pour les fichiers noyau est la suivante :
    • Nom du processus.
    • ID du processus.
    • Chaîne « noyau ».
    • Date/heure à laquelle le fichier noyau a été généré au format UNIX Epoch.
    • Par exemple, un fichier noyau pour DDFS peut être appelé « ddfs.core.14226.1469256407.gz ».
L’empreinte mémoire étant importante, la création d’un fichier noyau n’est pas immédiate et peut prendre plusieurs minutes pour être entièrement terminée.

Resolution

Comme indiqué ci-dessus, la création d’un fichier noyau n’est pas immédiate. Vous pouvez vérifier le répertoire /ddvar/core régulièrement via un partage NFS ou CIFS pour vous assurer que la création du fichier noyau est terminée. 

Une fois le fichier noyau créé, deux éléments d’information sont requis afin de déterminer ce qui a provoqué le redémarrage inattendu. Soit :
  1. Un nouveau bundle de support. Veuillez vous reporter à l’article suivant pour découvrir comment capturer et télécharger un bundle de support : https://support.emc.com/kb/323283
  2. Le fichier noyau généré lorsque le problème s’est produit. Reportez-vous à l’article suivant de la base de connaissances sur les différentes méthodes qui peuvent être utilisées pour télécharger et accéder à un fichier noyau : https://support.emc.com/kb/457974
Veuillez télécharger les éléments ci-dessus dans le dossier de support.

Affected Products

Data Domain

Products

Data Domain, DD OS, Data Domain Virtual Edition
Article Properties
Article Number: 000064290
Article Type: Solution
Last Modified: 19 Sept 2022
Version:  4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.