CephFS:什么是CAPS?

6-21 1,205 views

在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的速率与它必须释放的速率的对比

Latest posts by 青鸟千秋 (see all)

Ceph客户端缓存一致性分析

引子 在分布式系统中,保证客户端的缓存一致性非常重要。 假设有两个客户端Client A和Client B。集群的文件系统中有这么一个目录:/a/b/c/d/。 Client A创建...

阅读全文

Ceph集群快速搭建教程

本文的目标是在三台虚拟机上搭建Ceph集群,其中一台作为整个集群的服务器,另外两台只安装ceph-client作为客户端,可以挂载CephFS。 虚拟机系统:CentOS 7.6 ...

阅读全文

Win10 17074麦克风没声音bug解决方案

今天笔记本麦克风突然没声音重装声卡驱动也不好使 百度“win10麦克风没声音”无果,突发奇想:是不是微软这家伙的锅? 改成“win10 17074麦克风没声音”——竟然...

阅读全文

欢迎留言