文件大小的重要性低于在和调用文件之间发出的写入次数 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、挂载的 rsize 和 wsize 为256 KB、WAN延迟为64毫秒。执行此测试时、会对缓存和初始卷使用一个小型ONTAP Select实例、并执行单线程写入操作。结果可能有所不同。