CephFS：什么是CAPS？

在Ceph中，他们建立了一套独特的系统来管理客户端对Inode的操作权限，称为capabilities，简称CAPS。与其他网络文件系统（例如NFS或SMB）的主要区别之一是授予的CAPS非常精细，并且多个客户端可能在同一个inode上拥有不同的CAPS。

有一些“通用”的cap位，表示这些cap所赋予的是何种能力。

/* generic cap bits */
#define CEPH_CAP_GSHARED     1  /* client can reads (s) */
#define CEPH_CAP_GEXCL       2  /* client can read and update (x) */
#define CEPH_CAP_GCACHE      4  /* (file) client can cache reads (c) */
#define CEPH_CAP_GRD         8  /* (file) client can read (r) */
#define CEPH_CAP_GWR        16  /* (file) client can write (w) */
#define CEPH_CAP_GBUFFER    32  /* (file) client can buffer writes (b) */
#define CEPH_CAP_GWREXTEND  64  /* (file) client can extend EOF (a) */
#define CEPH_CAP_GLAZYIO   128  /* (file) client can perform lazy io (l) */

然后将它们移位特定数量的比特。这些表示正在授予cap的是inode数据或元数据的哪一部分：

/* per-lock shift */
#define CEPH_CAP_SAUTH      2 /* A */
#define CEPH_CAP_SLINK      4 /* L */
#define CEPH_CAP_SXATTR     6 /* X */
#define CEPH_CAP_SFILE      8 /* F */

只有某些通用cap类型会被做某些移位。特别是，只有FILE移位有超过前两位。

通过上面的操作，我们得到了一些常量，这些常量是通过取每个位值并移位到正确的位而生成的，例如：

#define CEPH_CAP_AUTH_SHARED  (CEPH_CAP_GSHARED  << CEPH_CAP_SAUTH)

然后可以将这些位组合在一起以形成表示一组能力的位掩码。

有一个例外：

#define CEPH_CAP_PIN  1  /* no specific capabilities beyond the pin */

“pin”只是将Inode固定到内存中，而不会授予任何其他cap。

图形描述：

+---+---+---+---+---+---+---+---+
| p | _ |As   x |Ls   x |Xs   x |
+---+---+---+---+---+---+---+---+
|Fs   x   c   r   w   b   a   l |
+---+---+---+---+---+---+---+---+

第二位当前未使用。

每个CAP授予的能力

● Pin — p               Inode存在于内存中
● Auth — A            身份认证元数据：mode, uid, gid
● Link — L              Inode的链接计数（有多少个dentries链接到这个Inode）
● Xattr — X            Inode的扩展属性，它们的存在这件事本身和它们的值
● File — F              文件数据，文件大小，最后修改时间等

● Shared — s         作为很多个拥有对这个状态的共享访问权限的client中的一个
● Exclusive — x      这个客户端是唯一能访问这个状态的（独占）
● Read — r             客户端能读取这个状态
● Write — w            客户端能写入这个状态
● Cache — c           客户端能在本地缓存这个状态
● Buffer — b            客户端能在本地缓冲写入变更

● 不是每个cap都用到所有许可
● pin：二元的，客户端能否记得Inode的存在
● Auth, Link, Xattr：共享（s）或独占（x）
● [ALX]s — 能保存状态到本地以供查阅
○ 我们能在客户端检查权限
● [ALX]x — 没有其他人能查看这个状态，我们“拥有”它
○ 我们可以在本地更改元数据而稍后再通知MDS！

● 不是每个cap都用到所有许可
● Fs：可以本地缓存并读取最后修改时间，文件大小
● Fx：可以本地写入最后修改时间，文件大小
● Fr： 可以读取文件数据（和OSD同步）
● Fc：可以缓存文件数据以供本地读取
● Fw：可以写入文件数据（和OSD同步）
● Fb：可以缓冲写入数据，在后台刷新

CAPS来自MDS

● MDS是元数据的最终权威
●每块元数据由一个锁控制（“simplelock”、“scatterlock”，“filelock”）决定如何共享该状态
   ○ 副本MDS有某些客户端没有的权限
   ○ 哪个cap能被授予哪些客户端
● 客户端发送元数据更新和cap获取请求
●大量的启发式方法根据这些输入改变锁定状态，以尝试和优化

CAPS如何变更？

● MDS可以对不同的客户端授予或撤销caps
    ○ 通常是由于别的客户端的活动导致
● 对于撤销的情况，客户端必须停止使用这个cap，并向MDS发生MClientCaps信息确认这一变更
    ○“停止使用”可能很容易也可能很困难：如果它是缓存或共享读取，仅仅只要丢弃数据并变更状态
    ○ 对缓冲写入等来说，客户端必须刷新掉所有脏数据——可能会花费大量时间！

CAP架构带来的后果

● MDS必须记住所有客户端固定的东西
    ○ 它必须追踪所有客户端
● 所以你的MDS的缓存必须比所有客户端的缓存还要大
● 因为caps是合作式的，需要工作或访问权限的客户端可能被别的客户端所阻挡

一些健康警告

客户端没有响应cap释放请求

● MDS已经发送cap撤销信息但是客户端没有返回
● 可能的原因：
    ○ 网络或OSD繁忙
    ○ 客户端收到了很多撤销信息，没有办法及时刷新所有
    ○ 软件Bug
    ○ 恶意用户
    ○ 客户端由于某些原因运行缓慢
● 默认60秒后打印这一信息
● mds_cap_revoke_eviction_timeout （默认： 0，关闭） 能设置为强制断开没有响应的客户端

客户端没有响应缓存压力

● MDS已经要求客户端释放一些固定住的Inode来减少内存使用，但是客户端没有释放足够的量
● 可能的原因：
    ○ 可能客户端非常活跃并且需要用到所有固定住的元数据，没有办法释放更多
    ○ 网络或OSD繁忙
    ○ 软件Bug
    ○ 恶意用户
    ○ 客户端由于某些原因运行缓慢
● 这个警告是一个非常复杂的衰减计数器，基于客户端释放caps的速率与它必须释放的速率的对比