ZFS-销毁重复数据删除的zvol或数据集会使服务器停顿。如何恢复？

我在带有12个中线（7200 RPM）SAS驱动器的HP ProLiant DL180 G6上运行的辅助存储服务器上使用Nexentastor。系统具有E5620 CPU和8GB RAM。没有ZIL或L2ARC设备。

上周，我创建了一个750GB的稀疏zvol，它具有dedup和压缩功能，可以通过iSCSI与VMWare ESX主机共享。然后，我创建了Windows 2008文件服务器映像，并将约300GB的用户数据复制到VM。对系统满意后，我将虚拟机移至同一池中的NFS存储。

在NFS数据存储上启动并运行我的VM之后，我决定删除原始的750GB zvol。这样做使系统停滞了。对Nexenta Web界面的访问和NMC暂停。我最终能够得到一个原始的shell。大多数OS操作都很好，但是系统挂在了该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解决方法之一提供的建议：

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

更新：我不得不强制关闭系统电源。重新启动后，系统将停在Importing zfs filesystems。现在已经有2个小时了。

这已经解决了。他们的关键是删除重复数据的卷需要在删除之前关闭dedup标志。这应该在池级别以及zvol或文件系统级别完成。否则，删除操作实际上将被删除重复数据。该过程需要时间，因为正在引用ZFS重复数据删除表。在这种情况下，RAM会有所帮助。我暂时向系统添加了16 GB的额外RAM，并使服务器重新联机。zpool在4小时内完全导入。

道德上可能是重复数据删除不是非常完美，RAM对于其性能至关重要。我建议24GB或更多，具体取决于环境。否则，请关闭ZFS重复数据删除。对于家庭用户或较小的系统，这绝对是不合理的。

作为Sun / Oracle ZFS 7000系列设备的长期用户，我可以毫无疑问地告诉您重复数据删除没有完善。切勿将销售与交货混淆！营业员会告诉您“哦，它已经固定”。在现实生活中-我的现实生活-我可以告诉您24GB不足以处理“ DDT表”。即，存储重复数据删除表的后端索引。该表必须驻留在系统内存中，以便在运行中拦截每个I / O，以便确定是否需要将其写入磁盘。您的存储池越大，数据更改就越多，该表越大，并且对系统内存的需求也越大。内存消耗了ARC（高速缓存），有时却消耗了OS本身-这就是为什么您会遇到挂起的原因，因为某些命令发生在前台，有些发生在后台。除非您在CLI中另有说明，否则似乎池删除发生在前台。GUI向导不会执行此操作。

如果没有足够的内存来处理对ZFS的“写入”，告诉它删除数据，那么即使在重复数据删除的卷上定义的共享中批量删除NFS数据，也将使系统减少一半。

总而言之，除非您最大程度地利用内存，否则即使如此，还是要找到一种通过限制ARC和DDT为OS保留内存的方法（而且我不认为您可以限制DDT的本质，它只是一个与之紧密相关的索引到您的I / O）-然后在进行大型删除或销毁zvol / pool时会陷入困境。