ZFS: la destrucción del conjunto de datos o zvol deduplicado detiene el servidor. ¿Cómo recuperarse?

Estoy usando Nexentastor en un servidor de almacenamiento secundario que se ejecuta en un HP ProLiant DL180 G6 con 12 unidades SAS de línea media (7200 RPM). El sistema tiene una CPU E5620 y 8 GB de RAM. No hay dispositivo ZIL o L2ARC.

La semana pasada, creé un zvol escaso de 750 GB con deducción y compresión habilitada para compartir a través de iSCSI a un host VMWare ESX. Luego creé una imagen del servidor de archivos de Windows 2008 y copié ~ 300GB de datos de usuario a la VM. Una vez satisfecho con el sistema, trasladé la máquina virtual a una tienda NFS en el mismo grupo.

Una vez en funcionamiento con mis máquinas virtuales en el almacén de datos NFS, decidí eliminar el zvol original de 750 GB. Hacerlo detuvo el sistema. El acceso a la interfaz web de Nexenta y NMC se detuvo. Finalmente pude llegar a una cáscara sin procesar. La mayoría de las operaciones del sistema operativo estaban bien, pero el sistema estaba suspendido en el zfs destroy -r vol1/filesystemcomando. Feo. Encontré las siguientes dos entradas de OpenSolaris bugzilla y ahora entiendo que la máquina estará bloqueada por un período de tiempo desconocido. Han pasado 14 horas, así que necesito un plan para poder recuperar el acceso al servidor.

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390

y

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=593704962bcbe0743d82aa339988?bug_id=6924824

En el futuro, probablemente tomaré los consejos dados en una de las soluciones alternativas de buzilla:

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

Actualización: tuve que obligar al sistema a apagarse. Al reiniciar, el sistema se detiene en Importing zfs filesystems. Ha sido así durante 2 horas ahora.

Esto ha sido resuelto. La clave es que los volúmenes deduplicados deben tener el indicador de deduplicación desactivado antes de la eliminación. Esto debe hacerse a nivel de grupo, así como a nivel de zvol o sistema de archivos. De lo contrario, la eliminación se deduplica esencialmente. El proceso lleva tiempo porque se hace referencia a la tabla de deduplicación de ZFS. En este caso, la RAM ayuda. Agregué temporalmente 16 Gigabytes de RAM adicionales al sistema y volví a conectar el servidor. El zpool importó completamente en 4 horas.

La moraleja probablemente sea que dedupe no está súper pulido y que la RAM es esencial para su rendimiento. Estoy sugiriendo 24 GB o más, dependiendo del entorno. De lo contrario, deje ZFS dedupe off. Definitivamente no es razonable para usuarios domésticos o sistemas más pequeños.

Como usuario desde hace mucho tiempo de los dispositivos Sun / Oracle ZFS serie 7000, puedo decirle sin dudas que dedupe no está pulido. ¡Nunca confunda las ventas con la entrega! Los vendedores le dirán "Oh, se ha solucionado". En la vida real, en mi vida real, puedo decir que 24 GB no son suficientes para manejar las "tablas DDT". Es decir, el índice de fondo que almacena la tabla de deduplicación. Esa tabla tiene que residir en la memoria del sistema para que cada E / S se intercepte en vuelo para determinar si es necesario escribirla en el disco o no. Cuanto mayor sea su grupo de almacenamiento, más cambios de datos, mayor será esta tabla, y mayor será la demanda en la memoria del sistema. Esa memoria viene a expensas de ARC (caché) y, a veces, del sistema operativo en sí, por lo que experimenta los bloqueos, ya que ciertos comandos ocurren en primer plano, algunos en segundo plano. Parece que la eliminación del grupo ocurre en primer plano, a menos que usted indique lo contrario en la CLI. Los asistentes de GUI no harán esto.

Incluso una eliminación masiva de datos NFS dentro de un recurso compartido definido en un volumen deducido reducirá su sistema a la mitad si no tiene suficiente memoria para procesar las "escrituras" en ZFS diciéndole que elimine los datos.

En general, a menos que maximice su memoria e incluso entonces, encuentre una manera de reservar memoria para el sistema operativo restringiendo ARC y DDT (y no creo que pueda restringir el DDT por naturaleza, es solo un índice vinculado exactamente a su E / S): luego se manguera durante borrados grandes o zvol / pools destory.