主页 / server / 问题 / 799295
Accepted
user121391
Asked: 2016-08-27 03:37:42 +0800 CST

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

  • 772

情况：

以下奇怪的问题发生在运行 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 内存 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 的问题。

zfs server-message-block file-server omnios microsoft-office-2010

1 个回答

  1. Best Answer

    解决方案：

    该问题仅影响 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 月。

    • 4

相关问题