我们有一个由两个 OpenSolaris 2009.06 NFS 服务器管理的光纤通道 san。
- 服务器 1 管理 3 个小卷（300GB 15K RPM 驱动器）。运行良好。
- 服务器 2 正在管理 1 个大型卷，其中包含 32 个驱动器（2TB 7200 RPM 驱动器）RAID6。总大小为 50TB。
- 两台服务器都具有 Zpool 版本 14 和 ZFS 版本 3。
几个月前安装了 50TB 的服务器，运行良好。用户占用了 2TB。我做了一个小实验（创建了 1000 个文件系统，每个文件系统都有 24 个快照）。创建、使用快照访问文件系统以及 NFS 安装其中一些文件系统时一切都很顺利。
当我尝试销毁 1000 个文件系统时，第一个文件系统花了几分钟，然后失败并报告文件系统正在使用中。我发出了系统关闭命令，但花了 10 多分钟。我没有再等，就关闭了电源。
现在启动时，OpenSolaris 挂起。32 个驱动器上的指示灯快速闪烁。我将其放置了 24 小时 - 仍然闪烁，但没有进展。
我在创建 zpool 之前启动了系统快照并尝试导入 zpool。
pfexec zpool import bigdata
相同情况：LED 闪烁并且导入永远挂起。
跟踪“zpool import”过程仅显示 ioctl 系统调用：
dtrace -n syscall:::entry'/pid == 31337/{ @syscalls[probefunc] = count(); }'
ioctl 2499
有没有办法来解决这个问题？编辑：是的。将 OpenSolaris 升级到 svn_134b 就可以了：
pkg publisher # shows opensolaris.org
beadm create opensolaris-updated-on-2010-12-17
beadm mount opensolaris-updated-on-2010-12-17 /mnt
pkg -R /mnt image-update
beadm unmount opensolaris-updated-on-2010-12-17
beadm activate opensolaris-updated-on-2010-12-17
init 6
现在我有 zfs 版本 3。Bigdata zpool 保持在版本 14。并且它已重新投入生产！
但是，在超过 24 小时的繁忙 I/O 访问下（软件升级之前），它都在做什么呢？
答案1
使用 ZFS，您确实希望让它直接操作磁盘，因为它可以提高并发性。您给它的单个 50TB 磁盘是一个瓶颈。
该 DTrace 脚本仅跟踪系统调用。实际操作发生在内核中，如果您想查看哪些程序占用了最多的 CPU，请使用 DTrace Toolkit 中的“hotkernel”脚本。
导入池时，ZFS 会从磁盘读取配置并进行验证。导入池后，它将开始挂载您创建的所有 1000 个文件系统和快照。这可能需要一段时间。如果您启用了重复数据删除（由于您使用的是 snv_111，因此没有启用），则需要更多时间，因为它必须加载重复数据删除表 (DDT)。
关闭系统从来都不是一个好选择，特别是在 OpenSolaris snv_111 上。您尚未发布池配置 (zpool status)，但是，如果您有 slog 设备并且它们发生故障，您将无法导入池（此问题最近已在 Solaris 11 Express snv_151a 中得到解决）。
我的建议是，您单独导出 32 个磁盘，并创建多个 raidz2 vdev，这样您就拥有更多的读/写磁头。不要创建包含超过 8 个磁盘的大型 vdev，因为这样性能会非常糟糕。
如果您无法承受系统停机这么长时间（大多数人都无法承受），请仔细研究 ZFS 快照以及如何使用 zfs send/receive 将它们复制到远程服务器。这将允许您快速启动故障转移服务器。
答案2
“zfs import” 或多或少只是直接读回 vdev 的配置（来自“zpool.cache”）。我猜这里花了很长时间才完成的原因是您的删除事务。
假设 ZFS 是事务性的，并且您删除了 1000 个文件系统，每个文件系统有 24 个快照，那么您将执行非常密集的删除操作，需要检查指向 24,000 个快照的引用指针。考虑到这些 SATA 磁头的寻道时间，以及需要执行的所有树更新。