相关疑难解决方法(0)

我已经阅读了很多有关规划 ZFS 重复数据删除的 RAM 要求的信息。我刚刚升级了我的文件服务器的 RAM，以支持 ZFS zvol 上的一些非常有限的重复数据删除，我无法在这些 zvol 上使用快照和克隆（因为它们是格式化为不同文件系统的 zvol），但会包含大量重复数据。

我想确保我添加的新 RAM 将支持我打算进行的有限重复数据删除。在计划中，我的数字看起来不错，但我想确定。

如何判断实时系统上 ZFS 重复数据删除表 (DDT)的当前大小？我阅读了这个邮件列表线程，但我不清楚他们是如何获得这些数字的。（zdb tank如有必要，我可以发布输出，但我正在寻找可以帮助其他人的通用答案）

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

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

在 NFS 数据存储上启动并运行我的 VM 后，我决定删除原来的 750GB zvol。这样做会使系统停滞。访问 Nexenta Web 界面和 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 解决方法中给出的建议：

Workaround
    Do not use dedupe, and do not attempt to destroy zvols …

如果我没有足够的 RAM 并且启用了重复数据删除选项的 ZFS 会发生什么情况？