一、起因
EFC（Elastic File Client）是 NAS 自研的分布式文件系统客户端，最近完成了对缓存架构的更新，现在支持多个客户端之间构成分布式缓存，底层支持 NAS、CPFS 和 OSS。由于开发时间较短，一直没有做 NAS 场景 CTO 测试的适配。
CTO：Close-to-Open，指当一个文件被关闭后，再次 open 时，文件系统必须保证之前所有通过 close 操作提交的数据已经持久化到文件系统，并且读取时能获取到最新的、一致的状态。CTO 测试的具体实现是对本地和远端文件系统的文件执行相同的操作，在某些操作后读取两端文件系统的内容，比较是否相同。
- 本地为 EXT4 文件系统，符合 POSIX 语义，远端文件系统跟本地文件系统对比，信任本地文件系统的表现。
- 读缓存的测试是分布式的，单客户端读取由分布式缓存提供服务。
最近忙里偷闲适配了一下，静静等待测试的通过，结果没想到发生了 data mismatch 的错误，因为关闭缓存直读 NAS 的 CTO 测试在每次发版前都会跑一遍。得，缓存的锅铁定没跑了，那咱就来看看这个问题。
二、错误类型判断
读数据错误？
EFC 读缓存在 NAS 场景下会使用 dv（data version）作为缓存的版本号，文件系统数据更新的时候会对 dv 自增。EFC 与文件系统通信的 RPC 会更新本地记录的 dv 信息，EFC 读缓存就会根据客户端手上的 dv 作为版本号从缓存读取数据。
由于这个机制的存在，所以 data mismatch 问题一眼认定为：使用了旧的 dv 读到了缓存里的旧数据。看来问题不大，喝口水压压惊。
CTO 测试会对本地文件和 NAS 上的文件执行相同的操作，并在执行某些操作后检查读到的文件是否一致。这样在读到缓存旧数据的情况下，本地文件（本地 /root 下）和远端文件系统的文件（NAS /mnt1 挂载下）内容是相同的。
由于 mnt1 还是通过 EFC 客户端进行挂载，读取数据还是走的缓存，依然存在读到旧数据的可能。因此，为了排除 EFC 缓存的影响，使用 NFS 协议挂载了 NAS 文件系统后（不通过 EFC 进行挂载），通过 diff 比较本地和 NAS 上的文件内容，结果两者竟然不一致。结果表明，文件系统数据被破坏掉了，也宣告着读到缓存中的旧数据的想法破产。
写数据错误！
调查过程陷入困局，决定看一下错误文件的内容有没有新的发现。由于原始文件存在大量的不可见字符，因此使用 hexdump 将文件转成 16 进制格式，每行显示 16 个字符。左侧为本地文件，右侧为 NAS 上文件，可以看到 NAS 上文件中的字符 f (0x66) 被替换成了空字符 NULL (0x00)。
但是 CTO 测试中并不会主动写入空字符，这些空字符是如何产生的呢？
计算错误字段的开始位置和结束位置：mismatch start = 0x94250 = 606800，mismatch end = 0x94ee0 + 2 = 610018，对一个 4K 页整除可以发现错误段正好位于一个 page 内。
这个 CTO 数据不一致问题几个小时的运行可以复现，每次结果的表现是一致的，均是正常字符被替换为空字符以及错误数据位于同一个 page 内（出现过数据错误开始位置正好 4K 对齐）。
这个时候开始把思路转向为：由于缓存的引入写坏了本地的 pagecache，当脏页需要刷到文件系统的时候把 pagecache 里的旧数据一并刷到了文件系统，造成了文件系统数据的不一致。
明确了问题后，现在的困扰来到了是什么操作写坏了 pagecache，以及空字符是如何产生的呢？
三、日志调查
在整个 CTO 测试期间，分析 EFC 缓存的日志，存在 6 条读缓存日志，并且命中缓存的仅有 3 条，错误也就发生在这 3 次读操作中。结合错误数据的 start offset (606208) 和 end offset (606208 + 3908 = 610116) 最终可以定位到第 3 次的读操作出错（606208 < 606800 < 610018 < 610116）。
进一步查看 CTO 测试日志，记录了每次读写操作的信息。可以看到，首先通过 op_write_append 操作追加写字符 f (0x66)，写的数据会首先存储在内核的 pagecache 中，然后通过 op_truncate_big 通知文件系统扩充文件长度到 610116，这样还没有被刷到文件系统的数据就是空字符 NULL (0x00)。接着通过op_fsync 将本地 pagecache 中的数据刷到文件系统。之后再通过 op_write_append 追加写字符 g (0x67)。
