NVMeOF/RDMA环境多客户端文件删除不同步原因及缓存清理方案问询

问题1：故障根因与底层原理 #

该问题不是单纯的内核页缓存导致，本质是架构选型的一致性缺失问题：

• NVMeoF/RDMA对外输出的是标准块设备，如果你直接将同一块设备在多个客户端分别挂载ext4/XFS等本地文件系统，这类本地文件系统从设计上就不支持多客户端并发挂载的一致性保障，每个节点的内核会独立维护自己的文件元数据（inode、dentry、块映射）缓存和页缓存，不同节点之间没有内置的元数据同步、变更通知机制。
• 你在单节点执行文件删除操作时，仅修改了该节点本地的元数据缓存，以及刷入块设备的元数据记录，其余客户端的内核已经缓存了test文件的元数据和数据块地址，不会主动感知块设备上的元数据变更。你执行的drop_caches系列命令仅能清理当前操作节点的本地缓存，无法触达其余客户端的缓存，自然无法让其他节点感知到文件删除操作。
• 该现象和RDMA绕过内核的特性没有直接关联，哪怕使用TCP协议的NVMeoF，只要是多节点并发挂载同一块本地文件系统，都会出现相同的一致性问题，严重时还会直接损坏整个文件系统的数据。

问题2：解决方案说明 #

首先明确：如果你的用法是多客户端直接挂载同一块NVMeoF块设备为本地文件系统，没有无需重新挂载就能实现跨节点元数据同步的方案，本地文件系统本身不支持分布式锁和变更通知的能力，硬要长期使用一定会出现数据损坏。
如果要合法实现多节点共享访问NVMe存储，建议调整为以下两类架构：

• 改用分布式文件系统：在NVMeoF块设备上层部署CephFS、Lustre、GlusterFS等原生支持多客户端一致性的分布式文件系统，自带分布式锁和元数据同步能力，文件删除、修改操作会实时同步到所有接入的客户端。
• 改用文件级共享协议：在目标节点将NVMe SSD格式化后的本地文件系统通过NFS、SMB协议共享给客户端，这类文件共享协议原生提供跨节点的元数据变更通知能力，不需要手动清理缓存即可让所有节点感知到文件操作。
  如果是临时测试场景必须保留多节点直接挂载块设备的用法，只能在单节点执行文件修改/删除操作后，强制所有其他客户端执行卸载再重新挂载块设备的操作，让内核重新读取块设备上的最新元数据。

内容的提问来源于stack exchange，提问作者shengjiang