我们有一个由两台OpenSolaris 2009.06 NFS服务器pipe理的光纤通道。
在几个月前安装了50TB的缓慢服务器，工作正常。 用户填满2TB。 我做了一个小实验（创build了1000个文件系统，每个都有24个快照）。 一切尽在创build，使用快照访问文件系统，NFS挂载其中的一些。
当我试图破坏1000个文件系统时，第一个fs花了几分钟，然后报告fs被使用失败。 我发出系统关机，但花了超过10分钟。 我没有再等了，关掉了电源。
现在启动时，OpenSolaris挂起。 32个驱动器上的指示灯快速闪烁。 我离开了24小时 – 仍在闪烁，但没有进展。
我在创buildzpool之前启动了系统快照，并尝试导入zpool。
pfexec zpool import bigdata 相同的情况：指示灯闪烁，导入永久挂起。
跟踪“zpool导入”过程只显示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访问量过大是怎么回事？
有了ZFS，你真的想让它直接操作磁盘，因为它提高了并发性。 你给它的单个50TB磁盘是一个窒息点。
DTrace脚本只跟踪系统调用。 真正的行为发生在内核中，如果你想看看大部分的CPU消耗了什么，使用DTrace Toolkit中的“hotkernel”脚本。
导入池时，ZFS将从磁盘读取configuration并对其进行validation。 在导入池之后，它将开始安装您创build的所有1000个文件系统和快照。 这可能需要一段时间。 如果您启用了重复数据删除function（因为您使用的是snv_111，您不需要这么做），因为它必须加载重复数据删除表（DDT），所以需要更多的时间。
closures系统绝不是一个好的select，特别是在OpenSolaris snv_111上。 您尚未发布池configuration（zpool状态），但是如果有slog设备并且失败，则无法导入池（最近在Solaris 11 Express snv_151a中已经解决了这个问题）。
我的build议是，你单独导出每个32个磁盘，并创build多个raidz2 vdev，所以你有更多的读/写头。 不要用大于8的磁盘创build巨大的vdev，因为性能会很糟糕。
如果系统停机时间过长（大多数人不这么做），请仔细研究ZFS快照，以及如何使用zfs发送/接收将其复制到远程服务器。 这将允许您快速启动故障转移服务器。
'zfs import'或多或less只是直接读回你的vdevsconfiguration（来自'zpool.cache'）。 我猜在这里永久采取的是你的删除交易。
鉴于ZFS是事务性的，并且您删除了1000个文件系统，每个文件系统都有24个快照，所以您需要进行非常密集的删除，并检查引用指针为24,000个快照。 鉴于这些SATA磁头的寻找时间，以及所有需要完成的树更新。