DDOS 5.7: El acceso al archivo con CIFS en MTree, el destino de la replicación de MTree, provoca estados de alarma o reinicios de DDFS, o identificadores de archivos obsoletos después de la actualización

Los restauradores de Data Domain (DDR) se pueden configurar para replicar el contenido de MTrees individuales en un sistema a un sistema remoto a través de la replicación de MTree (MREPL). A pesar de que el MTree en el destino es de solo lectura, aún se puede utilizar para acceder a los archivos replicados con fines de lectura/restauración/generación de informes o replicación saliente adicional.

Si el DDR de destino ejecuta DDOS 5.7 y se accede a un MTree utilizado como destino para MREPL a través de CIFS, el proceso de DD FS puede experimentar PÁNICO/reinicios (lo que causa una interrupción en la ejecución de respaldos/restauraciones/replicación) debido a un defecto en el código, con posibles firmas de PÁNICO como se muestra a continuación:
 

PÁNICO: fmcl/fm_inode.c: fm_iput_unpin: 468: fm_iput_unpin falló. Dirents aún presentes. PÁNICO: ddr/fm/fm_server.c: fms_write_segs: 1891: str == NULO PÁNICO: ddr/fm/fm_dm1_access.c: fm_dm1_access_intern: 203: fms_is_private_file_handle(&attr-fh>) && cred != g_nocred_p

Además, el cliente CIFS que se conecta al MTree a través de CIFS puede ver errores de "identificador no válido". Tenga en cuenta que este problema solo afecta a los DDR que ejecutan DDOS 5.7 y no se aplica a ninguna otra versión de DDOS.
 

Además, hay otra posible manifestación del mismo problema que puede ocurrir en DDOS 6.x o versiones posteriores, incluso cuando se corrige el defecto descrito (consulte a continuación para ver las versiones). La corrección original no pudo identificar otra ruta de código para el mismo defecto (es decir, cuando el FS de destino para el MTree que se utiliza para acceder a los archivos a través de CIFS está completamente lleno), lo que puede dar lugar a la misma cadena de PÁNICO a continuación, y que desde entonces se ha corregido en algunas versiones de DDOS 6.x:

09/12 01:56:30.847 (tid 0x7f557410ec20): ERROR: MSG-INTRNL-00001: PÁNICO: fmcl/fm_inode.c: fm_iput_unpin: 469: fm_iput_unpin falló. Dirents aún presentes.

DDOS 5.7 y versiones posteriores (que cambiaron por completo la implementación subyacente de SMB/CIFS en DDOS) incluyen una nueva funcionalidad que permite manejar archivos CIFS con estado. Este problema se debe a un defecto en la forma en que estos identificadores de archivos CIFS con estado interactúan con la funcionalidad de replicación de MTree.

Tenga en cuenta que se incluyó una corrección para este problema en las siguientes versiones de revisiones/parches de DDOS (tenga en cuenta que, a partir de septiembre de 2019, DDOS 5.7 ya no es una versión compatible):

• DDOS 5.7.1.10 y versiones posteriores
• DDOS 5.7.2.0 y versiones posteriores
• DDOS 5.7.32.0 (esta versión solo se aplica a los dispositivos virtuales Data Domain Virtual Edition/DDVE)

En este momento, los clientes deben actualizar a una versión de DDOS 6.x soportada, ya que la finalización del soporte para la familia DDOS 5.7 finalizó el 31 de enero de 2019.


Para el defecto de caso extremo que se puede detectar cuando el FS que actúa como destino para MREPL está 100 % lleno, no hay ninguna corrección en ninguna versión de DDOS 5.7, pero la hay en las siguientes versiones posteriores (y actualmente soportadas):

• DDOS 6.0.2.40 y versiones posteriores
• DDOS 6.1.2.30 y versiones posteriores
• DDOS 6.2.0.20 y versiones posteriores

Como en este caso (cuando el DD FS con problemas es del 100 %), es posible que no sea posible actualizar DDOS de inmediato debido a la falta de espacio de FS; una posible solución alternativa puede ser:

• Deshabilite toda la recopilación y los protocolos que se utilizan, así como la replicación
• Ejecute de forma limpia (incluso si el FS está 100 % lleno, debería completarse correctamente) y espere a que se complete
• Ahora que el FS ya no debería estar un 100 % lleno, tómese el tiempo para eliminar respaldos adicionales, buscar instantáneas antiguas, etc. y vuelva a ejecutar de forma limpia
• Cuando la cantidad de espacio de disco sea suficiente para evitar volver a llenar el FS, vuelva a habilitar los protocolos y reanude los respaldos
• Planifique la actualización a una versión fija para más adelante

Si el FS está inactivo o se bloquea repetidamente, póngase en contacto con el proveedor de soporte que contrató para que podamos ayudarlo con una solución alternativa.