CephFS 内部实现（二）：示例

之前面试时被问到描述下一个请求的完整流程，当时的结果很不理想，今天尝试重新组织下，记录在这里。

ceph-fuse1.png

这里有篇文章通俗易懂地描述了VFS层页缓存在cephfs中会有哪些“坑”以及相应策略。

mount后发生了什么？

ceph-fuse在不指定rootpath参数时，client端的root inode和mds的root一样。如果指定了rootpath参数，那么client端的root inode则是rootpath中的最后一个dentry的inode，不过从这个inode的往上一直到mds root inode的路径上的所有inode也都会在client端存一份副本（下图红色圆圈节点），这些父节点是为了计算quota时使用，比如quota可能设置在了mds root inode上，这时client端如果没有mds root inode则无法正确得到quota值，除此之外这些父节点inode别无他用。

rootpath=/dir时

ceph-fuse接收到的请求一定是关于一个inode的，这点可以通过Client::ll_xxx函数定义看出。而且这个inode必须是已经从mds获取过的。举例来说，刚mount完成时，client端的元数据信息只有root inode（及其父节点inode），这时FUSE是不会直接向client（即ceph-fuse）请求一个非root inode直接子节点的，这一点是由VFS+FUSE模块保证的。

打开文件

通过open()系统调用打开文件时，传入参数是一个路径，FUSE模块会从root节点一个dentry一个dentry地遍历（通过Client::ll_lookup()）路径，确保每个节点对应的inode都已经存在client端。如果在一个刚mount好的client中请求一个目录深度很深的路径，在系统调用上看只是一个请求，但实际上在client和mds间会产生多次通信，路径越深通信往返次数越多。
打开文件是需要给open()传入flat_t表示读写权限，这些系统flag在client端会先转换成CEPH_FILE_MODE_xxx，然后每个CEPH_FILE_MODE_xxx对应到一组CAP CEPH_CAP_xxx，如果client已经拥有所需CAP，则成功返回，否则向mds发起请求。

client侧看open()

在只有一个client时，client会作为loner拥有全部cap，这种情况比较简单，通常在一次请求内就能完成。稍微复杂些的是多个client的情况。

第二个client调用open(path,O_RDWR)时mds中的处理

当client2 向mds发送OP_OPEN后，MDS端由Server::handle_client_open()来进行处理。处理过程主要是图中的四步。
第一步加锁是常规操作，为了防止父节点被删除。
第二步issue_new_caps()在mds端记录client2 声称需要的cap，通过eval()驱动锁的状态进行转换，因为有新的client加入，且两个client都需要对文件进行写操作，这时IFILE lock从之前的EXCL状态向MIX转换，在本例的情况下（client1成功打开文件后，client2发起打开请求），EXCL到MIX的状态无法直接在MDS端完成，因为client1在之前作为loner被授予了过多cap，这些cap要先收回，才能继续向MIX转换。回收cap的是异步的，所以不会阻塞后续步骤。
第三步check_inode_max_size()是为了记录client2 对文件可写入的范围，这个数据作为client range被记录到日志中，用于故障恢复时使用。这一步需要对IFILE进行wrlock，这次加写锁时不会有问题的，因为根据状态机，EXCL->MIX状态下是允许EXL角色进行wrlock的，刚好client1作为loner是XCL角色，因此加锁不会失败。等日志落盘后锁会被释放，这时再根据当前状态判断是否发送新的cap给各个client，如果这时对client1的revoke cap还未完成，那么不会有新的cap发送给client，因为锁的状态没有改变，需要继续等对client1 cap的收回（当然这个等待是异步的）。整个第三步也不会阻塞后续步骤。
第四步将inode信息发回给client2。只有inode信息，没有cap，cap会在其他过程中单独发给client2（当mds完成对client1 的cap revoke时）。

读写文件

文件打开后在系统层只是拥有了文件句柄，在实际调用read()或write()前，文件的CAP可能还并没有完全授予给client，因此不论是Client::ll_read()还是Client::ll_write()都会先进行get_caps()，确保已经有相应cap，如果没有，就等待（通常情况下并不会向MDS发请求，因为没有cap说明之前的open()调用还没有真正结束，open()调用完成时需要有两个结果：1.inode信息被发回 2.cap被授予）。
读写文件需要的cap包括：

cap	用途
CEPH_CAP_FILE_RD	读文件需要
CEPH_CAP_FILE_WR	写文件需要
CEPH_CAP_FILE_CACHE	从本client的cache中读文件需要
CEPH_CAP_FILE_CACHE	从本client的cache中写文件需要

FILE_RD和FILE_WR是必须读写文件时的CAP。
FILE_CACHE和FILE_BUFFER对应常规文件系统里的缓冲概念，每个client都可以把文件内容cache在自己的内存中，如果使用内存中的数据，必须要有对应的这两个cap。
这四个cap在get_caps()时会增加cap的引用计数，在相应的读写操作从RADOS返回后，引用计数被减小。当cap的引用计数不为0时，即使收到了mds的revoke cap请求，client也是无法释放cap的。