OmniOS / ZFS / Windows 7: "Guardar como" dentro de las aplicaciones demora 5 segundos para todos los tamaños de archivos en CIFS / SMB

9

Situación:

El siguiente problema extraño ha ocurrido en un único servidor de archivos que ejecuta OmniOS r151018 (95eaa7e) que sirve archivos a través de SMB a invitados Windows y OS X.

Guardar ciertos archivos (.docx, .xlsx, algunas imágenes) a través del cuadro de diálogo "Guardar como ..." en un recurso compartido SMB resulta en un retraso de aproximadamente 3 a 5 segundos, donde la aplicación no responde en absoluto, luego el El archivo se guarda normalmente.

El problema ocurrió "durante la noche", sin hacerle nada al servidor, pero es difícil determinar la fecha exacta, ya que las quejas de los usuarios solo llegaron un tiempo después de la primera ocurrencia. Después de reiniciar el servidor, un vdev del grupo raíz duplicado no estaba disponible, pero una inspección más cercana no encontró fallas en el dispositivo y se volvió a conectar al grupo. El problema aún persiste.

Algunas observaciones

  • Sucede en todos los clientes de Windows 7
  • Sucede para todos los tamaños de archivo.
  • Sucede en todos los recursos compartidos de esta máquina, independientemente de los permisos
  • Sucede para un almacenamiento más rápido importado en el host a través de iSCSI desde otro servidor
  • La velocidad de copia normal es de 110 MB / seg. A través de GBit Ethernet
  • Los datos y el grupo raíz parecen estar bien
  • No sucede en otros servidores de archivos.
  • No sucede cuando el archivo se guarda localmente y luego se copia a través del explorador
  • No sucede en OS X (solo podría probarlo con OpenOffice)
  • dmesgmuestra varios recuentos NOTICE: bge0: interrupt: flags 0x0 - not updated?con varios valores, pero este también fue el caso antes y no hizo daño

Más ideas / planes:

Como no se encuentra un mensaje de error claro, es posible que deba realizar una prueba y error buscando la causa. Algunas cosas que consideraré (los resultados están en cursiva ):

  • Reemplazar la tarjeta de red Broadcom con una tarjeta Intel => no marcó la diferencia
  • Reemplace el grupo raíz con SSD SATA (actualmente memorias USB SLC que funcionaron bien durante más de 3 años) => no hizo la diferencia
  • Verifique la red intermedia (hardware, mediante conexión directa al servidor)
  • Captura de tráfico con WireShark: difícil si no sabe exactamente lo que está buscando
  • Vuelva a un entorno / versión de arranque anterior de OmniOS para descartar conflictos de software => no marcó la diferencia
  • Revierta las actualizaciones de Windows / Office para descartar errores

  • Eliminar archivos con :(dos puntos) en los nombres de archivo de las instantáneas, la sugerencia de txgsync en el hilo reddit creado por ewwhite => no marcó la diferencia

    He visto algo similar a esto cuando la característica "versiones anteriores" de Windows está habilitada con instantáneas automáticas que incluyen un carácter ":". Simplemente disparando al viento con esto, pero puede valer la pena echar un vistazo ya que el carácter ":" no está permitido en los nombres de archivos de Windows.

  • Monitoreo de acceso a archivos: como sugiere shodanshok, he utilizado DTracey esta secuencia de comandos para supervisar el acceso de archivos. Lo utilicé mientras guardaba el archivo abierto Alread, eliminé información personal y de salida no relacionada, y el resultado se centra en tres archivos:

    CPU ID       FUNCTION:NAME
1   18753    fop_open:entry Open: Workbook
0   18181 fop_create:return Create: temp_1
0   18753    fop_open:entry Open: temp_1
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: temp_1
0   18888  fop_rename:entry Rename: Workbook -> temp_2
0   18888  fop_rename:entry Rename: temp_1 -> Workbook
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: temp_2
0   18892  fop_remove:entry Remove: temp_2
0   18753    fop_open:entry Open: Workbook
0   18753    fop_open:entry Open: Workbook

    El mismo procedimiento en otro servidor donde el problema no ocurre produce un resultado similar:

    CPU ID       FUNCTION:NAME
1   25182 fop_create:return Create: temp_1
1   25750    fop_open:entry Open: temp_1
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_1
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_1
1   25889  fop_rename:entry Rename: Workbook -> temp_2
1   25889  fop_rename:entry Rename: temp_1 -> Workbook
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: temp_2
1   25893  fop_remove:entry Remove: temp_2
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: Workbook
1   25750    fop_open:entry Open: Workbook

    También agregué marcas de tiempo ( walltimestamp) al script, pero en ambos casos todas las operaciones de archivo tienen lugar en el mismo segundo. => no hizo la diferencia

  • Importe discos en otro host para verificar si la fragmentación del grupo o los discos están defectuosos => no hicieron la diferencia
  • Mover datos y agrupación root a la máquina idéntica a descartar el cableado, entre placas, etc. => problema no persistir, por lo que debe ser la agrupación raíz (software) o un hardware específico que es incompatible con el software (o dejó de repente hacen incompatibles. ..)

¿Podría sugerir algo más que sea la causa de este comportamiento? ¿O experimentaste algo similar? Debido a que no pude encontrar nada útil en línea, sospecho que es un extraño problema de hardware (porque está limitado a una máquina) o un problema con Windows / Office.

zfs server-message-block file-server microsoft-office-2010 omnios usuario121391
fuente
Ver: reddit.com/r/zfs/comments/4zo682/…
ewwhite
@ewwhite ¡Gracias por crear el hilo! La sugerencia fue realmente interesante, ya que, de hecho, algunas instantáneas en recursos compartidos tenían archivos perl que se copiaron de una máquina Unix, pero eliminarlos y las instantáneas no cambiaron el comportamiento.
user121391
Al guardar el archivo en un recurso compartido, Office tiene un comportamiento peculiar: primero crea un archivo vacío, luego lo elimina, finalmente vuelve a crear y guarda el archivo con sus datos. Si uno de estos pasos lleva más tiempo de lo esperado, la ventana "Guardar como" se congela efectivamente. ¿Tiene su sistema algunas facilidades para rastrear el acceso a nivel de archivo? ¿Puedes depurar la sesión SMB? ¿Está utilizando algo similar al servidor SMB integrado Samba o ZFS?
shodanshok
@shodanshok Gracias por su sugerencia, vea mi pregunta actualizada para obtener resultados. No sé por qué el pedido está ligeramente apagado, pero las marcas de tiempo parecen ser similares en ambas máquinas. Con respecto a su pregunta, es el servidor integrado Solaris / illumos CIFS, que actualmente utiliza SMB 2.1 IIRC.
user121391
¿Quizás el programa antivirus en los clientes de Windows 7 está causando el bloqueo?
Janne Pikkarainen

Respuestas:

4

Solución:

El problema solo afecta a OmniOS r151018, no a versiones anteriores. Este hilo en la lista de correo omnios-debate fue exactamente sobre mi problema, cita de Geoff:

Vi un hilo similar con el foro de Nexenta. Parece que hay un problema con opslock. Deshabilité opslock y estamos bien ahora.

svccfg -s network/smb/server setprop smbd/oplock_enable=false

No estoy seguro de por qué esto no está mordiendo a más personas.

Entonces, biteCount++;supongo. El problema se resolvió aplicando la solución y reiniciando rápidamente.

Lecciones para el futuro: antes de intentar cualquier solución de problemas, simplemente use la búsqueda avanzada en las listas de correo oficiales, porque lo más probable es que su problema ya haya ocurrido en la máquina de otra persona. Además, active una máquina virtual rápida para descartar cualquier error de software, actualizaciones o configuración antes de buscar errores de hardware.

Cómo llegué allí:

Después de varias pruebas diferentes como se ve en la pregunta actualizada, lo reduje a problemas de software o conflictos de hardware / controlador en el hardware específico. Para descartar el segundo, instalé dos máquinas virtuales OmniOS nuevas, r151018 y r151016 en otro host y configuré manualmente un recurso compartido SMB básico en cada una de ellas.

El r151018 experimentó el problema, el r151016 funciona bien. Sospecho que no lo noté en mis primeras pruebas, porque solo revertí algunas actualizaciones en r151018, no a una versión anterior. Creo que el problema debe haber existido más de lo que suponía.

Al buscar una manera de actualizar los paquetes uno por uno, miré la lista de correo y busqué en smblos últimos 6 meses, donde apareció la solución correcta / el mismo problema, que data de mayo.

usuario121391
fuente