1
OmniOS / ZFS / Windows 7：对于CIFS / SMB上的所有文件大小，应用程序中的“另存为”滞后5秒
情况： 在运行OmniOS r151018（95eaa7e）的单个文件服务器上，通过SMB向Windows和OS X guest虚拟机提供文件时，发生了以下奇怪的问题。 通过SMB共享上的“另存为...”对话框窗口保存某些文件（.docx，.xlsx，某些图像）会导致大约3到5秒的延迟，之后应用程序完全不响应。文件正常保存。 该问题确实发生在“一夜之间”，没有对服务器做任何事情，但是很难确定确切的日期，因为用户的抱怨只是在第一次出现之后的某个时间出现的。重新引导服务器后，镜像的根池的一个vdev不可用，但仔细检查未发现设备上的任何故障，并将其重新连接到池中。问题仍然存在。 一些观察： 它发生在所有Windows 7客户端上 适用于所有文件大小 无论权限如何，它都会在此计算机的所有共享上发生 这样做是为了通过另一台服务器通过iSCSI在主机上更快地导入存储 在GBit以太网上，正常复制速度为110 MB /秒 数据和根池似乎很好 在其他文件服务器上不会发生 当文件保存在本地，然后通过资源管理器复制时，不会发生这种情况 在OS X上不会发生（只能在OpenOffice上进行测试） dmesg可以显示NOTICE: bge0: interrupt: flags 0x0 - not updated?具有不同值的多个计数，但是以前也是如此，并且没有害处 进一步的想法/计划： 由于找不到明确的错误消息，因此可能需要进行一些反复试验以查找原因。我会考虑的一些事情（结果以斜体显示）： 用Intel卡替换Broadcom网卡=>没有什么区别 用SATA SSD替换根池（当前SLC内存USB记忆棒可以使用3年以上）=>没有区别 检查之间的网络（硬件，通过直接连接到服务器） 使用WireShark捕获流量：如果您不知道确切要查找的内容，则很难 恢复到以前的OmniOS引导环境/版本以排除软件冲突=>没什么不同 回滚Windows / Office更新以排除错误 :从快照中删除文件名中带有（冒号）的文件，txgsync对ewwhite =>创建的reddit线程的建议没有什么影响 使用包含“：”字符的自动快照启用Windows“先前版本”功能时，我已经看到类似的内容。只是随风而行，但可能值得一看，因为Windows文件名中不允许使用“：”字符。 监测的文件访问：由shodanshok建议，我用DTrace和这个脚本监视文件访问。我在保存已打开的文件，删除不相关的输出和个人信息时使用了它，结果集中在三个文件周围： CPU ID FUNCTION:NAME 1 18753 fop_open:entry …