情况：

在运行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 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: Workbook
  

  我还向walltimestamp脚本添加了时间戳（），但是在两种情况下，所有文件操作都在同一秒发生。=>没有改变

• 在另一台主机上导入磁盘以检查池碎片或磁盘是否有故障=>没有区别
• 将数据和根池移到同一台计算机上以排除电缆，主板等。=>问题确实仍然存在，因此必须是根池（软件）或与该软件不兼容的特定硬件（或者突然变得不兼容）。 ..）

您能否提出导致此问题的其他原因？还是您遇到过类似的事情？因为找不到在线有用的东西，所以我怀疑这是一个奇怪的硬件问题（因为它仅限于一台计算机）还是Windows / Office问题。

解：

该问题仅影响OmniOS r151018，而不影响以前的版本。omn​​ios-discuss邮件列表上的该线程恰好与我的问题有关，引用Geoff的话：

我在Nexenta论坛上看到了类似的话题。opslock似乎有问题。我禁用了opslock，我们现在很好。

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

不知道为什么这不会咬人。

所以，biteCount++;我猜。通过应用此修复程序并进行快速重新启动来解决了该问题。

未来的经验教训：尝试进行任何故障排除之前，只需使用官方邮件列表中的高级搜索，因为您的问题很可能已在其他人的计算机上发生。此外，在查找硬件错误之前，启动快速VM可以排除所有软件，更新或配置错误。

我如何到达那里：

在更新的问题中进行了几次不同的测试之后，我将其范围缩小到特定硬件上的软件问题或硬件/驱动程序冲突。为了排除第二个，我在另一台主机上安装了两个新的OmniOS虚拟机r151018和r151016，并在每个虚拟机上手动配置了基本SMB共享。

r151018遇到了问题，r151016正常运行。我怀疑我在最初的测试中没有注意到它，因为我只回滚了r151018上的某些更新，而不回滚到早期版本。我认为这个问题存在的时间肯定比我想象的要长。

当寻找一种仅一次更新软件包的方法时，我查看了邮件列表并smb从最近的6个月开始搜索，在那里弹出了正确的解决方案/相同的问题，其始于5月。