我读过ZFS在所有顶级vdevs的zpool中划分数据，假设所有的vdev都是在池的开始时添加的。 我读过的一切似乎都认为这是一件好事。 但是，在我看来，对于使用多个磁盘的部署来说，这并不会导致多用户（甚至是多进程）环境中的所有这些磁盘的良好整体性能。
例如，假设我有96个磁盘，我使用这些磁盘创build12个每个8个磁盘的vdevs，所有这些都添加到我的zpool中。 然后，我把它放在用户身上，用各种疯狂的手段填满它。 有些文件是几十千兆字节，有些则是小型用户应用程序configuration文件等。
之后，用户A想要复制一些多GB的文件。 她启动了一个rsync或者其他的，并且从12个条纹vdevs的底层连续读取中体验到了惊人的性能。 但是随后用户B启动了另一个同时请求相当大的数据块的应用程序。 现在硬盘正在不断的拉下用户A的rsync来处理用户B，尽pipe每个应用都是单独的相对顺序的，但是96个硬盘都参与了这两个用户的请求，并且看到的查找模式和性能与随机I / O.
在这12个vdev的8个磁盘configuration中，每个vdev仍然有8个磁盘的性能价值，所以我希望即使没有其他vdevs的附加条带，顺序I / O也是非常好的。 ZFS在将一个vdev放在另一个vdev上之前不是更好吗？ （在我的实验中，我得到了大约500k的条带）。这样，用户A的读取将只有1/12的机会使用相同的磁盘作为用户B的读取，他们都会获得性能与连续的I /大部分时间
在这种configuration/工作负载下，有没有办法从ZFS中获得良好的性能？
ZFS总是覆盖所有的vdevs ，尽pipe取决于文件需要多less个块 – 小文件通常会放入单个块中，因此只落在单个vdev上，除非它们属于configuration了copies = 2或copies = 3的数据集。
不，你不能改变它，或者不分开池。
为了提高这种条带式设置的性能，ZFS在ZIO组件中包含了自己的IO调度程序（这就是为什么在linux 最后期限或noop调度程序被推荐的情况下）。
改进这种工作负载的另一层是ARC ，其中包括预取caching。 您可以在单独的快速设备上使用L2ARC加速ARC，相当于同步写入为SLOG（专用ZIL设备）。