情况：

在运行 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 年）=> …

我的目标是在结合 SATA 磁盘的小型 OpenSolaris NAS（在 HP Microserver N54L 上运行 OmniOS + napp-it）上自动执行备份程序。

背景：

我安装了其中一个 5.25" -> 3.5" 无托架硬盘托盘，其中包含一个简单的 SATA 或 SAS/SATA 背板，带有一个端口、一个电源按钮和一些 LED（电源和硬盘活动）。为了备份多个 HDD（每周轮换一个，异地存储），我编写了一个脚本，用于zfs send/recv转储完整的主池，包括所有快照（仅更新新块）。当我手动启动它时，这个脚本工作正常。

我想进一步自动化该过程，因为 NAS 没有直接连接 VGA 或串行控制台，插入磁盘、返回桌面系统、登录 Web 界面或 SSH 并手动启动脚本很繁琐. 通过 cron 作业定时启动不是一种选择，因为备份的日期可能略有不同（忘记磁盘、假期等）。所以备份应该在插入磁盘后立即开始。

问题：

在我cfgadm用来连接 + 配置和稍后取消配置 + 断开磁盘的脚本中。如果我只插入磁盘并且它旋转起来，我就无法知道磁盘在那里。我已经考虑过的可能解决方案：

1. 通过使用cfgadm -f -c connect和检查错误结果，每 x 分钟连续探测新磁盘和 zpool 。不是很优雅。
2. /var/adm/messages每 x 分钟检查一次并搜索设备路径或 AHCI。不可能，因为只有在手动连接设备时才会写入消息。
3. 使用iostat -En. 显示磁盘，但我必须 grep 获取确切的序列号，因为它没有列出端口信息。还需要每 x 分钟完成一次。
4. 使用cfgadmSELECT 语法过滤插座状态。不起作用，因为插入不会触发任何东西（也许背板太便宜了）。
5. 识别机柜的电源开/关。会好的，但我无法弄清楚如何实现这一点。
6. 重新映射电源按钮或向机器添加另一个按钮。可以工作，但我也不知道如何做到这一点。

我想我需要两件事：

• 一种结合识别磁盘和端口状态的可靠方法（因此仅检测到正确插槽中的正确磁盘）
• 一种注册此检测并触发事件的方法（启动 …

情况：

在集成的一体化 ESXi/ZFS 存储服务器上，其中存储 VM 使用裸机磁盘并通过 NFS（或 iSCSI）将文件系统导出回 ESXi，后者将其用作其他 VM 的池存储，存在更新存储虚拟机时会出现问题，因为许多正在运行的虚拟机依赖于它，并且会因NFS.AllPathsDown或类似原因而超时，这等于从普通服务器中拉出驱动器而不将其关闭。

当然，可以关闭所有 VM，但这会变得非常耗时且乏味（或必须编写脚本）。将 VM 移动到另一台主机可能是可能的，但需要更长的时间，并且在较小的设置中可能无法实现，其中一台机器就足够了。暂停虚拟机可以工作，但也很慢（有时比关闭慢）。

可能的解决方案...

1. 一个简单而有效的解决方案似乎是通过 CLI 停止 VM 进程，在使用kill -STOP [pid]找到它后ps -c | grep -v grep | grep [vmname]，执行存储 VM 的升级/重新启动，然后使用 继续执行 VM 进程kill -CONT [pid]。
2. 一个类似的解决方案可能是快速重启（在 Solaris/illumos 上可用reboot -f或在 Linux 上可用）的组合，kexec-reboot这需要几秒钟而不是几分钟，以及 ESXi 中的 NFS 超时（在 NFS 连接丢失时，所有 I/O 都被暂停，我认为120 秒，直到假定存储永久关闭）。如果重新引导时间在 ESXi NFS 窗口内，理论上它应该类似于磁盘由于纠错而在一分钟内没有响应，然后恢复正常操作。

……还有问题？

现在，我的问题是：

1. 哪种方法更可取，或者它们同样好/坏？
2. 在数据库、Active Directory 控制器、用户运行作业的机器等特殊情况下，有哪些意想不到的副作用？
3. 应该注意哪里？链接博客上的评论提到，例如，当 CPU …