我在运行 HP ProLiant DL180 G6 的二级存储服务器上使用 Nexentastor，该服务器配有 12 个 Midline (7200 RPM) SAS 驱动器。系统配有 E5620 CPU 和 8GB RAM。没有 ZIL 或 L2ARC 设备。
上周，我创建了一个 750GB 的稀疏 zvol，启用了重复数据删除和压缩功能，以便通过 iSCSI 共享到 VMWare ESX 主机。然后，我创建了一个 Windows 2008 文件服务器映像，并将约 300GB 的用户数据复制到 VM。对系统感到满意后，我将虚拟机移至同一池上的 NFS 存储。
在 NFS 数据存储上启动并运行我的虚拟机后，我决定删除原始的 750GB zvol。这样做会导致系统停滞。对 Nexenta Web 界面和 NMC 的访问停止。我最终能够获得原始 shell。大多数操作系统操作都很好，但系统挂在命令上zfs destroy -r vol1/filesystem。太糟糕了。我发现了以下两个 OpenSolaris bugzilla 条目，现在我明白机器将在一段未知的时间内处于瘫痪状态。已经 14 个小时了，所以我需要一个计划才能重新获得对服务器的访问权限。
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390
和
将来，我可能会采纳 buzilla 解决方法之一中给出的建议：
Workaround
Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.
更新：我不得不强制关闭系统。重启后，系统停滞在Importing zfs filesystems。这种情况已经持续了 2 个小时。
答案1
这个问题已经解决了。关键是删除重复数据卷之前需要关闭重复数据删除标志。这应该在池级别以及 zvol 或文件系统级别完成。否则，删除本质上就是重复数据删除。这个过程需要时间，因为要引用 ZFS 重复数据删除表。在这种情况下，RAM 会有所帮助。我临时为系统添加了 16 GB 的 RAM，然后让服务器重新上线。zpool 在 4 小时内完全导入。
结论可能是重复数据删除功能不够完善，而 RAM 对其性能至关重要。我建议内存为 24GB 或更多，具体取决于环境。否则，请关闭 ZFS 重复数据删除。对于家庭用户或较小的系统来说，这绝对不合理。
答案2
作为 Sun/Oracle ZFS 7000 系列设备的长期用户，我可以毫无疑问地告诉你，重复数据删除并不完善。千万不要将销售与交付混为一谈！销售人员会告诉你“哦，已经修好了”。在现实生活中——我的现实生活中——我可以告诉你 24GB 不足以处理“DDT 表”。即存储重复数据删除表的后端索引。该表必须驻留在系统内存中，以便每个 I/O 在运行中被拦截，以确定是否需要将其写入磁盘。存储池越大，数据更改越多，该表就越大 - 并且对系统内存的需求也越大。该内存是以 ARC（缓存）为代价的，有时甚至是操作系统本身 - 这就是您遇到挂起的原因，因为某些命令发生在前台，而有些命令发生在后台。似乎池删除发生在前台，除非您在 CLI 中另有说明。GUI 向导不会这样做。
如果没有足够的内存来处理对 ZFS 的“写入”并告诉其删除数据，那么即使在重复数据删除卷上定义的共享内大量删除 NFS 数据也会使您的系统性能下降一半。
总之，除非你用尽你的内存，否则即使这样，也要通过限制 ARC 和 DDT 找到为操作系统保留内存的方法（我不认为你可以从本质上限制 DDT，它只是一个与你的 I/O 完全相关的索引）——否则你会在进行大量删除或破坏 zvol/pools 时陷入困境。