ファイルサイズは、ファイルの呼び出しと呼び出しの間に実行される書き込み数よりも重要ではありません OPEN CLOSE 。サイズの小さいファイルは本質的に呼び出し回数が少なく、ライトバックにはあまり WRITE 適していません。サイズの大きいファイルは、との呼び出しの間に多くの書き込みが行われる可能性があります OPEN CLOSE が、これは保証されません。

最大ファイルサイズに関する最新の推奨事項については、ページを参照して"FlexCacheライトバックのガイドライン"ください。

クライアントからの書き込みでは、書き込みコール以外の変更NASコールが関係します。これらには以下が含まれますが、これらに限定されません。

SETATTR SET_INFO、 atime、 ctime owner、、 group、またはを size`設定したコールは `mtime、キャッシュで処理されます。これらの呼び出しの残りの部分はオリジンで処理され、ライトバックが有効なキャッシュに蓄積されたダーティデータのライトバックをトリガーする必要があります。ライトバックが完了するまで、ファイルへのIOは休止されます。

これらの呼び出しがWANを経由する必要があることを知っておくと、ライトバックに適したワークロードを特定するのに役立ちます。一般的に、 OPEN `CLOSE`上記のいずれかの呼び出しを発行しなくても、との呼び出しの間に実行できる書き込み数が多いほど、パフォーマンスの向上によるライトバックが向上します。

FlexCacheでは、これまでリードアフターライトワークロードのパフォーマンスが低下していました。これは、9.15.1より前のライトアラウンド動作が原因です。 WRITE`ファイルへの呼び出しはオリジンでコミットされる必要があり、後続の呼び出しでは `READ データをキャッシュに戻す必要があります。これにより、両方の動作がWANのペナルティを受けることになります。そのため、ライトアラウンドモードのFlexCacheでは、リードアフターライトワークロードは推奨されません。9.15.1でライトバックが導入されたことで、データはキャッシュにコミットされ、キャッシュから即座に読み取ることができるようになり、WANのペナルティが解消されました。ワークロードにFlexCacheボリュームでのリードアフターライトが含まれている場合は、キャッシュをライトバックモードで動作するように設定する必要があります。

ファイルがキャッシュにダーティデータを蓄積すると、キャッシュはデータを非同期的に元のデータに書き込みます。これは当然のことながら、クライアントがダーティデータがオリジンへのフラッシュバックを待機している状態でファイルを閉じた場合に発生します。クローズされたばかりのファイルに別のオープンまたは書き込みが入ってきてもダーティデータが残っている場合、すべてのダーティデータがオリジンにフラッシュされるまで書き込みは中断されます。

FlexCacheがライトバックモードで動作している場合は、レイテンシが増加するとNASクライアントの方が有利になります。ただし、低レイテンシの環境で得られる利点よりも、ライトバックのオーバーヘッドが大きくなる点があります。一部のNetAppテストでは、ライトバックのメリットは、キャッシュとオリジンの間の最小レイテンシが8ミリ秒前後で始まっていました。このレイテンシはワークロードによって異なります。ワークロードのポイントオブリターンをテストして確認してください。

次のグラフは、NetAppラボテストにおけるライトバックのポイントを示しています。 x`軸はファイルサイズで、 `y 軸は経過時間です。このテストではNFSv3を使用し、とを256KBにマウントし、 rsize wsize 64ミリ秒のWANレイテンシを実現しました。このテストでは、キャッシュとオリジンの両方に小さいONTAP Selectインスタンスを使用し、1回のスレッド書き込み処理を実行しました。結果は異なる場合があります。