OmniOS/ZFS/Windows 7：对于 CIFS/SMB 上的所有文件大小，应用程序中的“另存为”延迟 5 秒

Question

情况：

在运行 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?具有不同值的多个计数，但这也是之前的情况并且没有伤害

进一步的想法/计划：

由于没有找到明确的错误消息，我可能需要进行一些反复试验以寻找原因。我会考虑的一些事情（结果以斜体显示）：

• 用 Intel 卡替换 Broadcom 网卡=> 没有区别
• 用 SATA SSD 替换根池（目前 SLC 内存 U 盘可以正常工作超过 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 的问题。

Answer 1

解决方案：

该问题仅影响 OmniOS r151018，不影响之前的版本。omn​​ios-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 月份。