更新：由于logging大小默认为128k，testing程序读取的数据量远大于8GB系统上的ARC，并且比16GB系统上的ARC稍大。 减lesslogging大小允许读取更less的数据，因此它适合于ARC。 我低估了正在阅读的数据的大小，logging的效果，因此得出了一些可怜的结论。 到目前为止，禁用预取在这种情况下似乎没有太大的区别，但是我打算尝试使用和不使用预取的所有logging选项。
这种负载类似于IMAP / Maildir场景，其中包含许多目录，许多文件以及可能从每个文件中读取的less量数据。
我已经使用zfsonlinuxtesting了FreeBSD 10和Fedora 19。 我testing了各种各样的Linux本地文件系统，如extX / xfs / jfs甚至btrfs。 在FreeBSD上，我也使用本地ufs文件系统进行了testing。 我的工作量只是使用amarok / winamp /等扫描一个大的音乐collections。 我的testing程序是amarok_collectionscanner，因为它可以轻松地从命令行运行。 模式总是一样的。 集合扫描程序的初始运行大约需要10分钟，具体取决于文件系统，但ZFS与非ZFS文件系统的运行方式相似
后续的扫描使用非zfs文件系统的速度非常快，通常在30秒左右。 ZFS在随后的运行中只做了一点改进。 从iostat上看，在非ZFS文件系统上初始运行后，操作系统不会触及磁盘。 全部在文件系统caching中。
为ZFS使用固态盘caching可以缩短时间，但从不会在30秒左右。
为什么ZFS不caching这个负载？ 我探索的一种可能性是，ARC的大小被限制为小于非ZFS文件系统被允许用于高速caching的大小。 我在一台机器上再次testing了ARC的可用内存，而不是第一个testing系统上的全部可用内存，并且数字保持不变。
我希望find/创build一个复制这种负载的fio配方。 基本上它需要创build数以千计的小文件，扫描所有寻找文件的目录，打开每个文件并从每个文件中读取less量的数据。 这就像世界上最糟糕的数据库！ 我可能会testingOpenIndiana，但我希望结果是一样的。
数据集是353GB和49,000个文件。 testing系统有8GB-16GB的RAM。 zpoolconfiguration几乎没什么区别，但我关心的testing总是只有一个整盘。 我使用了ST3500630AS和WDC WD20EZRX-00D8PB0等驱动器。 驱动器几乎没有区别。 RAM的数量或者CPU的速度几乎没有差别。 只有正在使用的文件系统改变了结果，这些差异是相当大的，正如我上面提到的。 我实际上有关于我试过的各种文件系统参数的数据点的山峰，这些是我检查的一些variables：mdadm raidconfiguration（0和1）zpoolconfiguration，镜像和条带zfs recordsize mdadm块大小文件系统块大小
在单个ST3500630AS驱动器上，我得到了以下文件系统的默认文件系统选项的这些数字。 这是在Fedora 19上，8GB的RAM，3.11.10-200内核，ZFS 0.6.2-1。 这些值以秒为单位。 后续扫描没有任何尝试清除caching运行。
ZFS: 900, 804, 748, 745, 743, 752, 741 btrfs: 545, 33, 31, 30, 31, 31 ext2: 1091, 30, 30, 30, 30, 30... ext3: 1014, 30, 30, 30, 30, 30... ext4: 554, 31, 31, 32, 32, 31, 31... jfs: 454, 31, 31,31,31... xfs: 480, 32, 32, 32, 32 ,31 ,32, etc. 在FreeBSD 10上，单一硬盘WD20EZRX-00D8PB0，更快的机器，16GB的内存，允许ARC增长到12GB：
ufs: 500, 18, 18... zfs: 733, 659, 673, 786, 805, 657
尽pipe上面的variables有时会影响数据的初始冷藏caching扫描，但后续的运行看起来都是一样的。 标准的文件系统将其全部caching起来，因此只要没有其他任何事情使得caching快速闪电。 ZFS不显示该行为。
从禁用atime开始，如果尚未完成。
您也可以调查设置primarycache=metadata影响。
在FreeBSD上，安装sysutils / zfs-stats
作为该软件包一部分的“zfs-mon”工具将为您提供有关ZFS（ARC，ARC元数据，ZFETCH，预取等）中每个不同typescaching的caching命中/未命中率的详细信息。
此外，扫描时“zpool iostat 1”可能会有所帮助
默认情况下，“元数据”caching限制为ARC的1/4，您可以使用vfs.zfs.arc_meta_limit loader.conf可调参数调整此值
在FreeBSD 10中，ARC统计数据包含在“顶部”，观察扫描过程中这些数值的变化可能会提供一些见解