eww*_*ite 11 zfs nfs opensolaris deduplication nexenta
我在带有 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
和
将来，我可能会采纳其中一种 buzilla 解决方法中给出的建议：
Workaround
Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.
更新：我不得不强制系统关闭电源。重新启动后，系统停在Importing zfs filesystems。就这样已经2个小时了。
eww*_*ite 15
这已经解决了。他们的关键是重复数据删除的卷需要在删除之前关闭重复数据标记。这应该在池级别以及 zvol 或文件系统级别完成。否则，删除实际上是在进行重复数据删除。该过程需要时间，因为正在引用 ZFS 重复数据删除表。在这种情况下，RAM 会有所帮助。我临时向系统添加了 16 GB 的额外 RAM，并使服务器重新联机。zpool 在 4 小时内完全导入。
道德可能是重复数据删除不是超级完善的，而且 RAM 对其性能至关重要。我建议使用 24GB 或更多，具体取决于环境。否则，请关闭 ZFS 重复数据删除。对于家庭用户或较小的系统来说，这绝对是不合理的。
小智 5
作为 Sun/Oracle ZFS 7000 系列设备的长期用户，我可以毫无疑问地告诉您重复数据删除没有完善。永远不要混淆销售和交付！销售人员会告诉你“哦，已经修好了”。在现实生活中——我的现实生活中——我可以告诉你 24GB 不足以处理“DDT 表”。即存储重复数据删除表的后端索引。该表必须驻留在系统内存中，以便每个 I/O 都在运行中被拦截，以确定是否需要将其写入磁盘。你的存储池越大，数据变化越多，这个表越大——对系统内存的需求也越大。该内存以牺牲 ARC（缓存）为代价，有时还会以操作系统本身为代价 - 这就是您遇到挂起的原因，因为某些命令发生在前台，有些在后台。似乎池删除发生在前台，除非您在 CLI 中另有说明。GUI 向导不会这样做。
如果您没有足够的内存来处理对 ZFS 的“写入”，告诉它删除数据，即使在重复数据删除卷上定义的共享中大量删除 NFS 数据也会使您的系统减半。
总而言之，除非你最大限度地利用内存，即使那样，通过限制 ARC 和 DDT 找到一种为操作系统保留内存的方法（我认为你不能从本质上限制 DDT，它只是一个精确绑定的索引到您的 I/O） - 然后在大型删除或销毁 zvol/pools 期间您会被灌水。
| 归档时间： |
|
| 查看次数： |
3338 次 |
| 最近记录： |