情况：

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

在 Solarispkg update -nv上会列出新的软件包。

在 CentOS 上，可以通过yum changelog.

在将它们安装到 Solaris/OmniOS 上之前，是否可以阅读每个可用软件包的更新日志？

我有一个测试设置，其中包含：

• 3 个 AD 域控制器（设置为在它们之间复制），均在 Univention Corporate Server 4.1 上运行 Samba 4.3
• 1 个 Windows 7 SP1 客户端加入域
• 1 台运行 napp-it 16.02f 的 OmniOS r151018 文件服务器加入域，并为某些域测试用户设置了 SMB/CIFS 共享

域按我的预期工作，Windows 登录工作，文件服务器访问工作，DNS 以及直接 IP 连接工作，甚至在关闭一个 DC 时故障转移工作。

唯一不起作用的是我在 Windows 7 机器上的网络浏览器/网络邻居中看不到 OmniOS 机器。搜索所有计算机时，我可以在“搜索 Active Directory”中找到它，也可以使用\\hostname（或 IP）连接到它而不会出现问题或延迟。它似乎并没有正确地宣传自己。其他 3 台服务器和 Windows 机器本身正如人们所期望的那样，只有在机器关闭时才会消失。

在搜索解决方案时，我发现了设置属性的建议，但它似乎没有做任何事情，即使在重新启动后也是如此。smbsystem_comment

另外，我还注意到，与 r151012 相比，随着 OmniOS r151016 和 r151018 的更新，通常在工作组模式下的直接发现不再起作用（只能通过 IP 访问）。这可能与我的问题有关，也可能与我的问题无关，除了合并到这些 OmniOS 版本中的 illumos 版本的“SMB 支持中的多项更改”之外，我找不到任何更详细的信息。

这个问题/不便的原因可能是什么，我该如何解决？作为一种解决方法，网络驱动器的直接映射会起作用，但如果共享数量增加，这可能会出现问题。

在 Solaris 及其变体上，它会生成当前/文件系统的 zfs 克隆并在那里安装新内核。重新启动时，您将获得新的/.

在我的情况下，我有一个/scripts目录，所以如果我应该回到以前的内核，那么我/scripts也会被回滚，这对我来说应该与我所在的内核无关。

问题

从内核升级完成到主机重新启动，如何避免丢失对文件系统所做的更改？

是否有一个我不知道的过程，因为即使您在内核升级后非常快地重新启动，也很容易创建日志条目，而您永远不会看到。