Data Domain: Se produjo un reinicio inesperado de DDFS (sistema de archivos de Data Domain) con la alerta EVT-FILESYS-00008/FILESYS-00008 o EVT-FILESYS-00010/FILESYS-00010 o EVT-FILESYS-00011/FILESYS-00011

Summary: En este artículo de la base de conocimientos, se explica lo que sucede cuando se produce un reinicio inesperado del sistema de archivos, las posibles alertas encontradas y la información que se debe capturar con fines 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



El proceso de DDFS es el proceso principal responsable de la operación del sistema de archivos de deduplicación de DDOS (Data Domain Operating System).

Si este proceso encuentra un problema, se crea una alerta que será una de las siguientes:
  • EVT-FILESYS-00008/FILESYS-00008
  • EVT-FILESYS-00010/FILESYS-00010
  • EVT-FILESYS-00011/ FILESYS-00011
Las alertas anteriores indican que el problema detectado fue inesperado y se requiere más información para determinar la causa.

La alerta se enviará a través del mecanismo de alerta configurado en el sistema Data Domain, es decir, a través de correo electrónico/snmp. La alerta también aparecerá en la salida "alerts show history".

Cause

Este proceso puede reiniciarse de varias maneras, por ejemplo:
  • Un estado de alarma directo, es decir, un error de código explícito.
  • Se encuentra un tiempo de espera interno. DDFS tiene un subproceso de monitor de latido interno (llamado hmon) que supervisa el estado de los diversos subsistemas dentro del proceso de DDFS. Si hmon determina que un subsistema ha suspendido o ha estado esperando demasiado tiempo, finaliza el proceso de DDFS.
  • Se encuentra un tiempo de espera externo. Un proceso denominado ddr_stated es responsable de monitorear externamente el proceso de DDFS mediante un mecanismo de latido. Si DDFS no envía un latido a ddr_stated dentro de un período determinado, ddr_stated supone que DDFS ha suspendido y finaliza el proceso de DDFS.
  • El proceso solicita más memoria de la que se permite.
  • Falló una comprobación de sanidad interna.
Cuando se encuentra cualquiera de estas condiciones, el sistema de archivos intenta reiniciarse automáticamente para reanudar el funcionamiento normal. 

Durante el reinicio de DDFS, todas las operaciones que estaban en curso, como restauraciones/respaldos, es decir, lecturas/escrituras, se interrumpirán y deberán reiniciarse. La mayoría de las aplicaciones de respaldo pueden reconocer que las lecturas/escrituras se interrumpieron y reiniciar estas operaciones automáticamente.

Cuando se produce un reinicio inesperado de DDFS, suceden las siguientes cosas:
  • El proceso se detiene.
  • El espacio físico de memoria que el proceso estaba utilizando se escribe en un "archivo principal" que se escribirá en un dispositivo de volcado de memoria, que es un área especial en uno de los discos de la unidad principal. Un archivo principal contiene la información necesaria para depurar por qué se produjo el reinicio inesperado.
  • Una vez que se completa el paso anterior, el proceso de DDFS puede reiniciarse.
  • En paralelo, es decir, una vez que DDFS se reinicia, el archivo principal se debe extraer del dispositivo de volcado principal a un sistema de archivos de DDOS, de modo que se pueda acceder a él. El proceso que realiza esta tarea se denomina "savecore".
  • Savecore crea un directorio temporal inicial en /ddvar/core. El nombre del directorio se denominará "app-<date and time the core file>".
  • Dado que DDFS utiliza la mayoría de la memoria en el sistema, el espacio físico de la memoria para DDFS puede ser grande. Para minimizar la cantidad de datos escritos en el archivo principal, savecore lee desde el dispositivo de volcado principal, transmite esta información a través de gzip, para asegurarse de que el archivo principal sea lo más pequeño posible y comienza a escribir en un archivo llamado "core-incomplete.gz".
  • Una vez que se complete este proceso, se eliminará el directorio temporal, el archivo principal se colocará en /ddvar/core y se cambiará el nombre. La convención de asignación de nombres para un archivo principal es la siguiente:
    • El nombre del proceso.
    • El ID del proceso.
    • La cadena "core".
    • La fecha y hora en que se generó el núcleo en un formato unix epoch.
    • Por ejemplo, un archivo principal para DDFS podría denominarse "ddfs.core.14226.1469256407.gz".
Debido a que el espacio físico de la memoria es grande, la creación de un archivo principal no es inmediata y puede tardar varios minutos en completarse por completo.

Resolution

Como se mencionó anteriormente, la creación del archivo principal no es inmediata, el directorio /ddvar/core se puede comprobar periódicamente a través de un recurso compartido NFS o CIFS para determinar cuándo se completó la creación del archivo principal. 

Una vez finalizada la creación del archivo principal, se requieren dos elementos de información para clasificar lo que causó el reinicio inesperado. Estos son los siguientes:
  1. Un nuevo paquete de soporte. Consulte el siguiente artículo sobre cómo capturar y cargar un paquete de soporte: https://support.emc.com/kb/323283
  2. El archivo principal generado cuando se produjo el problema. Consulte el siguiente artículo de la base de conocimientos sobre los diversos métodos que se pueden utilizar para cargar y acceder a un archivo principal: https://support.emc.com/kb/457974
Cargue los elementos anteriores en el caso de soporte.

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.