「通常の」ファイルシステムがこのワークロードを完全にキャッシュするのに、なぜzfsはこのワークロードをキャッシュできないのですか？
更新：recordsizeのデフォルトは128kであるため、テストプログラムによって読み取られるデータの量は、8GBシステムのARCよりもはるかに多く、16GBシステムのARCよりもわずかに多くなります。レコードサイズを小さくすると、読み取るデータが少なくなるため、ARCに適合します。私は、読み取られるデータのサイズ、それに対するレコードサイズの影響を過小評価していたため、いくつかの悪い結論を導き出しました。これまでのところ、プリフェッチを無効にしても、この場合はあまり違いがないようですが、プリフェッチを有効にしているかどうかに関係なく、すべてのレコードサイズオプションを試してみます。
この負荷は、多くのディレクトリ、多くのファイル、および各ファイルから読み取られるデータの量が少ない可能性があるIMAP/Maildirシナリオに似ています。
FreeBSD10とFedora19をzfsonlinuxで使用してテストしました。 extX/xfs/jfsやbtrfsなど、さまざまなLinuxネイティブファイルシステムをテストしました。 FreeBSDでは、ネイティブのufsファイルシステムも使用してテストしました。私のワークロードは、amarok/winamp/etcを使用して大規模な音楽コレクションをスキャンするだけです。私のテストプログラムは、コマンドラインから簡単に実行できるため、amarok_collectionscannerです。パターンは常に同じです。コレクションスキャナーの最初の実行には、ファイルシステムによって異なりますが、約10分かかりますが、ZFSは非ZFSファイルシステムと同様に実行されます。
その後のスキャンの実行は、zfs以外のファイルシステムを使用すると非常に高速で、通常は約30秒です。 ZFSは、その後の実行でわずかな改善しか行いません。また、iostatを見ると、ZFS以外のファイルシステムで最初に実行した後、OSがディスクにアクセスしないことも明らかです。それはすべてファイルシステムのキャッシュにあります。
ZFSにSSDキャッシュを使用すると時間が短縮されますが、30秒近くになることはありません。
ZFSがこの負荷をキャッシュしないのはなぜですか？私が調査した1つの可能性は、ARCのサイズが非ZFSファイルシステムがキャッシュに使用できるサイズよりも小さく制限されていることでした。最初のテストシステムで使用可能なメモリ全体よりもARCで使用可能なメモリが多いマシンで再度テストしましたが、数値は同じままでした。
この種の負荷を複製するfioレシピを見つけて作成したいと思っています。基本的には、何千もの小さなファイルを作成し、すべてのディレクトリをスキャンしてファイルを探し、各ファイルを開いて、各ファイルから少量のデータを読み取る必要があります。それは世界最悪のデータベースのようなものです！次にOpenIndianaをテストしますが、結果は同じになると思います。
データセットは353GB、49,000ファイルです。テストシステムには8GB〜16GBのRAMが搭載されていました。 zpool構成による違いはほとんどありませんが、私が気にするテストは常に1つのディスク全体でした。他のドライブの中でもST3500630ASとWDCWD20EZRX-00D8PB0を使用しました。ドライブはほとんど違いがありませんでした。 RAMまたはCPUの速度はほとんどまたはまったく違いがありませんでした。使用中のファイルシステムのみが結果を大幅に変更し、上記のようにそれらの違いはかなりのものでした。私が試したさまざまなファイルシステムパラメータに関するデータポイントと、これらは私がチェックした変数の一部です：mdadm raid構成（0および1）zpool構成、ミラーおよびストライプzfs recordsizemdadmチャンクサイズfilesystemblocksize
単一のST3500630ASドライブで、次のファイルシステムのデフォルトのファイルシステムオプションとしてこれらの番号を取得しました。これはFedora19、8GBのRAM、3.11.10-200カーネル、ZFS0.6.2-1にありました。値は秒単位です。後続のスキャンは、キャッシュをクリアしようとせずに実行されました。
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
上記の変数がデータの最初のコールドキャッシュスキャンに影響を与えることがありましたが、それ以降の実行はすべて同じように見えます。標準のファイルシステムはそれをすべてキャッシュするため、キャッシュを破壊するものが他にない限り、非常に高速に実行されます。 ZFSはその動作を示しません。
まだ行っていない場合は、atimeを無効にすることから始めます。
primarycache=metadataの影響の設定を調査することもできます。
FreeBSDで、sysutils/zfs-statsをインストールします
そのパッケージの一部である「zfs-mon」ツールは、ZFSのさまざまなタイプのキャッシュ（ARC、ARCメタデータ、ZFETCH、プリフェッチなど）のそれぞれのキャッシュヒット/ミス比に関する詳細を提供します。
また、スキャン中の「zpooliostat1」が役立つ場合があります
デフォルトでは、「メタデータ」キャッシュはARCの1/4に制限されています。この値は、vfs.zfs.arc_meta_limitloader.conf調整可能で調整できます。
FreeBSD 10では、ARC統計は「top」に含まれています。スキャン中にこれらの値がどのように変化するかを監視することで、洞察が得られる場合があります。