cephfs的cap

cap是什么？最初15年做cephfs的时候几乎没有任何文档参考，只能依靠“代码是最好的文档”的信念去学习。最近社区的Greg Farnum（以前cephfs的leader）的slides把cap讲的很明确，顺便学习一下。

cap的设计涉及cephfs一致性。这里会有一个分布式锁的概念。类似的实现还有samba的oplocks以及NFS的delegation。mds具有管理和分配元数据的能力，分布式锁描述了其他mds是否有获取和改变这些元数据的能力，以及客户端操作cap的能力，如是否允许缓存、是否可以在客户端本地修改时间等。

cephfs cap组成

每个元数据可以按照内容划分为5个部分，

p － pin指该inode存在

A － 代表Auth，即对于mode、uid、gid的操作能力

L － Link，即inode和dentry相关的count的操作能力

X － 代表Xattrs，即对于扩展属性的操作能力

F －代表File，即对文件大小（size）、文件数据和mtime的操作能力

另外每个部分最多对应有6种对应操作能力

s － shared 共享能力，即改数据可由多客户端获得，1对多的模型

x － exclusive 独占能力，只有该客户端

r － read 具有读能力

w －write 具有写能力

c －cache 读具有缓存能力，可以在客户端缓存读数据

b － buffer 客户端有缓存写的能力，即写的数据可以缓存在本地客户端

几种常见举例

一般ALX对应s或者x

AsLsXs － 只有客户端可以读和本地缓存相关的元数据状态

AxLxXx － 只有该客户端可以读和改变相关的元数据状态

Fs － 可以在本地缓存和读取mtime和文件大小的能力

Fx － 拥有在本地写mtime和文件大小的能力

Fr －可同步地从OSD中读取数据

Fc －可从缓存读取客户端中的数据

Fw － 拥有同步地写入OSD中数据的能力

Fb － 拥有优先写入缓存的能力，即先入objectcacher然后异步写入OSD

如何操作cap

cap是由mds管理的（这点毋庸置疑，所有元数据都归mds管）。客户端发送对cap的更新和请求。

元数据的每一个部分被mds的相关锁SimpleLock/ScatterLock/FileLock（这部分还没有仔细研究）进行管理。mds授权（grant）或者取消（revoke）cap，对应的客户端会使用或者丢掉（drop）对应的cap。drop的过程可能简单如缓存读，直接把读数据丢掉即可，也可能比较麻烦如缓存写，需要把数据刷到OSD（objecter往osd发送信息）。

带来的负面效果有3点：1、客户端所pin的文件，在mds中都需要记录；2、mds的缓存会变得比所有客户端合起来都大；3、cap必须操作正确否则会阻塞其他客户端的访问。

另外，lazyio已经在内核客户端和fuse客户端实现，它面向的是hpc场景，允许更上层的app自行处理一致性而不是由存储系统解决。

想看代码的可以移步内核和fuse的读写函数。

其他

该slides对概念上的介绍比较详细，但还需要进一步了解一些内容，以便对整套机制有全面的了解：

1、对cap操作的例子特别是客户端并发访问，具体还需要看实现；

2、mds端的各种锁实现；

3、cephfs在分布式锁上使用的模型；