小编Man*_*Man的帖子

Gluster + ZFS，基准测试期间死锁：zfs_iput_taskq 100% cpu

首先是一些背景：我在一家运行 PHP 网络应用程序的公司工作。我们在多个网络服务器上通过 NFS 安装了一个存储后端。今天我们遇到了一个问题，如果一个网络服务器通过 NFS 写入文件，有时该文件直到几分钟后才会出现在其他安装的客户端上。它也不是多余的，因此我们无法执行任何“隐形”维护。

我一直在考虑迁移到 GlusterFS 解决方案（两个或三个复制的砖块/机器以实现冗余）。现在，使用 XFS 作为 Gluster “背后”的存储文件系统效果很好，性能也很好。Gluster 似乎也没有上面提到的同步问题。

但是，我想使用 ZFS 作为后端文件系统，原因是；

便宜的压缩（当前存储 1.5TB 未压缩）
很容易扩展存储卷“实时”（一个命令，比较 LVM 一团糟）
快照、位腐烂保护和所有其他 ZFS 荣耀。

在我的解决方案演示设置中，我有三台带有 Replicated Gluster 的服务器，在每台服务器上的单独磁盘上都有一个 ZFS 后端池。我在 Linux (0.6.2) + GlusterFS 3.4 上使用 CentOS 6.5 和 ZFS。我也尝试过 Ubuntu 13.10。一切都在 VMware ESX 中。

为了测试这个设置，我在 Gluster 上安装了卷，然后运行 BlogBench ( http://www.pureftpd.org/project/blogbench ) 来模拟负载。我遇到的问题是，在测试结束时，ZFS 存储似乎陷入僵局。所有三台机器都有“zfs_iput_taskq”以 90-100% 的 CPU 运行，并且测试冻结。如果我中止测试，僵局不会消失，唯一的选择似乎是硬重启。

我试过了：