情况：
在运行 OmniOS r151018（95eaa7e）并通过 SMB 为 Windows 和 OS X 客户机提供文件的单个文件服务器上出现了以下奇怪的问题。
通过 SMB 共享上的“另存为...”对话框窗口保存某些文件（.docx、.xlsx、某些图像）会导致大约 3 到 5 秒的延迟，其中应用程序根本没有响应，之后文件会正常保存。
问题确实在“一夜之间”发生，对服务器没有任何影响，但很难确定确切日期，因为用户投诉是在第一次发生后不久才出现的。重新启动服务器后，镜像根池的一个 vdev 不可用，但仔细检查后未发现该设备有任何故障，并将其重新连接到池中。问题仍然存在。
一些观察：
- 它发生在所有 Windows 7 客户端上
- 它适用于所有文件大小
- 它发生在这台机器的所有共享上，无论权限如何
- 这种情况发生在通过 iSCSI 从另一台服务器导入主机的更快存储时
- 通过 GBit 以太网的正常复制速度为 110 MB/秒
- 数据和根池似乎没有问题
- 其他文件服务器上不会发生这种情况
- 当文件保存在本地，然后通过资源管理器复制时，不会发生这种情况
- 在 OS X 上不会发生这种情况（只能使用 OpenOffice 进行测试）
dmesg显示多个NOTICE: bge0: interrupt: flags 0x0 - not updated?具有不同值的计数，但以前也出现过这种情况，并且没有造成任何损害
进一步的想法/计划：
由于没有找到明确的错误消息，我可能需要反复试验才能找到原因。我会考虑以下几点（结果以斜体显示)：
- 将 Broadcom 网卡更换为 Intel 网卡=> 没什么区别
- 将根池替换为 SATA SSD（目前为 SLC 内存 USB 棒，已运行良好超过 3 年）=> 没什么区别
- 检查中间的网络（硬件，通过直接连接到服务器）
- 使用 WireShark 捕获流量：如果你不知道自己到底在寻找什么，那就很困难
- 恢复到以前的 OmniOS 启动环境/版本以排除软件冲突=> 没什么区别
- 回滚 Windows/Office 更新以排除错误
从快照中删除
:文件名中带有（冒号）的文件，这是 ewwhite 创建的 reddit 线程中 txgsync 的建议=> 没什么区别当 Windows 的“以前版本”功能启用时，我曾看到过类似的情况，其中自动快照包含“:”字符。这只是在瞎猜，但可能值得一看，因为 Windows 文件名中不允许使用“:”字符。
监控文件访问：按照 shodanshok 的建议，我使用
DTrace了这个脚本监控文件访问。我在保存已打开的文件时使用它，删除了不相关的输出和个人信息，结果围绕三个文件：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在另一台没有发生问题的服务器上执行相同的过程，得到类似的结果：
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: Workbookwalltimestamp我还在脚本中添加了时间戳（ ），但在两种情况下，所有文件操作都在同一秒发生。=> 没什么区别- 在另一台主机上导入磁盘以检查池碎片或磁盘是否有故障=> 没什么区别
- 将数据和根池移至相同的机器以排除电缆、主板等。=> 问题确实仍然存在，因此一定是根池（软件）或与软件不兼容的特定硬件（或者突然变得不兼容......）
您能建议导致此行为的其他原因吗？或者您遇到过类似的事情吗？因为我在网上找不到任何有用的信息，所以我怀疑这要么是一个奇怪的硬件问题（因为它仅限于一台机器），要么是 Windows/Office 的问题。
答案1
解决方案：
该问题仅影响 OmniOS r151018，不影响之前的版本。此主题在 omnios-discuss 邮件列表中正好有关于我的问题，引用 Geoff 的话：
我在 Nexenta 论坛上看到了类似的帖子。似乎 opslock 存在问题。我禁用了 opslock，现在一切正常。
svccfg -s network/smb/server setprop smbd/oplock_enable=false不确定为什么这没有影响到更多的人。
所以，biteCount++;我猜。通过应用修复程序并快速重启，问题已经解决。
未来的教训：在尝试任何故障排除之前，只需使用官方邮件列表中的高级搜索，因为您的问题很可能已经发生在其他人的机器上。此外，在查找硬件错误之前，请快速启动虚拟机以排除任何软件、更新或配置错误。
我是如何到达那里的：
经过更新问题中提到的几次不同测试后，我将问题缩小到软件问题或特定硬件上的硬件/驱动程序冲突。为了排除第二种情况，我在另一台主机上安装了两个全新的 OmniOS 虚拟机 r151018 和 r151016，并在每个虚拟机上手动配置了一个基本的 SMB 共享。
r151018 遇到了这个问题，r151016 运行正常。我怀疑我在第一次测试中没有注意到它，因为我只回滚了 r151018 上的一些更新，而不是回滚到较早的版本。我认为这个问题存在的时间一定比我想象的要长。
当寻找一种仅逐个更新软件包的方法时，我查看了邮件列表并搜索了smb过去 6 个月的情况，其中出现了正确的解决方案/相同的问题，可追溯到 5 月份。