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 上的文件内容，结果两者竟然不一致。结果表明，文件系统数据被破坏掉了，也宣告着读到缓存中的旧数据的想法破产。
