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 recuentosNOTICE: 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 diferenciaHe 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: WorkbookEl 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: WorkbookTambié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.