我在使用12个Midline（7200 RPM）SAS驱动器的HP ProLiant DL180 G6上运行的辅助存储服务器上使用Nexentastor。 该系统有一个E5620 CPU和8GB RAM。 没有ZIL或L2ARC设备。
上周，我创build了750GB稀疏zvol，并启用了重复数据删除和压缩function，通过iSCSI将其共享到VMWare ESX主机。 然后，我创build了Windows 2008文件服务器映像，并将大约300GB的用户数据复制到VM。 一旦系统满意，我将虚拟机移动到同一个池上的NFS存储。
一旦在NFS数据存储上运行我的虚拟机，我决定删除原来的750GB zvol。 这样做使系统停滞不前。 访问Nexenta网页界面和NMC停止。 我终于能够得到一个生壳。 大多数操作系统操作都很好，但系统挂在zfs destroy -r vol1/filesystem命令上。 丑陋。 我发现了以下两个OpenSolaris bugzilla条目，并且现在明白了该机器将会在未知的时间段内变砖。 已经14个小时了，所以我需要一个能够重新获得服务器访问权的计划。
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390
和
http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=593704962bcbe0743d82aa339988?bug_id=6924824
将来，我可能会采取一些buzilla解决方法给出的build议：
Workaround Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.
更新：我不得不强制系统closures。 重新引导后，系统在Importing zfs filesystems系统中停顿。 现在已经是这样2个小时了。
这已经解决了。 他们的关键是，删除之前，重复数据删除卷需要closures重复数据删除标记。 这应该在池级别以及zvol或文件系统级别完成。 否则，删除基本上是重复数据删除。 由于正在引用ZFS重复数据删除表，因此该过程需要时间。 在这种情况下，RAM有帮助。 我暂时添加了16个额外的千兆字节的RAM到系统，并使服务器重新联机。 zpool在4小时内完全导入。
道德可能是重复数据删除不是超级抛光，内存对其性能至关重要。 我build议24GB或更多，这取决于环境。 否则，请将ZFS重复数据删除。 家庭用户或小型系统绝对不合理。
作为Sun / Oracle ZFS 7000系列设备的长期用户，我可以毫无疑问地告诉你，数据删除不会被打磨。 永远不要混淆销售和交付！ 销售人员会告诉你“哦，它已经被修复了”。 在现实生活中 – 我的真实生活 – 我可以告诉你24GB是不足以处理“滴滴涕表”。 即存储重复数据删除表的后端索引。 该表必须驻留在系统内存中，以便每个I / O在运行中被拦截，以便确定是否需要将其写入磁盘。 存储池越大，数据更改越多，此表越大，对系统内存的需求也越大。 这个内存是以ARC（caching）为代价的，有时候是操作系统本身 – 这就是为什么你会遇到挂起问题，因为某些命令发生在前台，一些发生在后台。 似乎池的删除发生在前台，除非您在CLI中另行说明。 GUI向导不会这样做。
如果您没有足够的内存来处理向ZFS的“写入”，告诉它删除数据，即使大量删除在重复卷上定义的共享中的NFS数据，也会将系统减半。
总而言之，除非你最大限度地减less了内存，甚至可以通过限制ARC和DDT来为操作系统预留内存（我不认为你可以限制DDT的本质，它只是一个索引到你的I / O） – 那么你在大的删除或destory zvol / pools期间被洗脑。