注意
本文档适用于 Ceph 的开发版本。
CephFS 分布式元数据缓存
虽然 Ceph 文件系统中 inode 的数据存储在 RADOS 中并由客户端直接访问，但 inode 元数据和目录信息由 Ceph 元数据服务器 (MDS) 管理。MDS 作为所有元数据相关活动的调解器，将生成的信息存储在与文件数据分开的 RADOS 池中。
CephFS 客户端可以请求 MDS 代表其获取或更改 inode 元数据，但 MDS 也可以为每个 inode 授予客户端能力（也称为 caps）（请参阅CephFS 中的能力）。
能力授予客户端缓存并可能操作与 inode 关联的数据或元数据的一部分的能力。当另一个客户端需要访问相同信息时，MDS 将撤销该能力，客户端最终将返回它，以及 inode 元数据的更新版本（以防它在持有能力期间对其进行了更改）。
客户端可以请求能力，并且通常会获得它们，但是当存在竞争访问或 MDS 上的内存压力时，它们可能会被撤销。当能力被撤销时，客户端有责任尽快返回它。未能及时返回的客户端最终可能会被列入黑名单，并且无法与集群通信。
由于缓存是分布式的，因此 MDS 必须非常小心，以确保没有客户端持有可能与其他客户端的能力或它自己执行的操作相冲突的能力。这使得 cephfs 客户端可以依赖比 NFS 等文件系统更大的缓存一致性，其中客户端可能会缓存数据和元数据，超出服务器上已更改的时间点。
客户端元数据请求
当客户端需要查询/更改 inode 元数据或对目录执行操作时，它有两种选择。它可以直接向 MDS 发出请求，或者从其缓存中提供信息。对于 CephFS，后者只有在客户端具有必要的 caps 时才可能实现。
客户端可以向 MDS 发送简单请求以查询或请求更改某些元数据。这些请求的回复也可能授予客户端针对 inode 的一组特定 caps，允许它在不咨询 MDS 的情况下执行后续请求。
客户端也可以直接向 MDS 请求 caps，这对于读取或写入文件数据是必需的。
MDS 集群中的分布式锁
当 MDS 想要读取或更改有关 inode 的信息时，它必须为它收集适当的锁。MDS 集群可能对给定的 inode 具有一系列不同类型的锁，并且每个 MDS 可能具有不相交的锁集。
如果有未完成的 caps 会与这些锁冲突，那么必须在获取锁之前撤销它们。一旦竞争的 caps 返回到 MDS，它就可以获取锁并执行操作。
在由多个 MDS 服务的文件系统上，元数据缓存也分布在集群中的 MDS 之间。对于每个 inode，在任何给定时间，集群中只有一个 MDS 被认为是权威的。任何更改该 inode 的请求都必须由权威 MDS 完成，尽管非权威 MDS 可以将请求转发给权威 MDS。
非权威 MDS 也可以获取读取锁，防止权威 MDS 更改数据，直到释放锁为止，这样它们就可以向客户端提供 inode 信息。
inode 的权威 MDS 也会随着时间而变化。MDS 会积极地在它们之间平衡 inode 缓存的责任，但这可以通过将某些子树固定到单个 MDS 来覆盖。