mkdir函数_cephfs: MDS处理mkdir(1)

之前记录了《cephfs：用户态客户端mkdir》，但是并没有具体研究MDS怎么处理mkdir的。现在就研究下MDS这边处理mkdir的流程。例子：mkdir /test/a

MDS对于来自客户端请求的通用处理

通用处理流程

在上面的图中可以看出，在正式处理mkdir请求之前，先处理了请求中附带的cap_realse消息，即函数Locker::process_request_cap_release；

Locker::process_request_cap_release

process_request_cap_release用来处理请求中ceph_mds_request_release消息，ceph_mds_request_release中的caps就是客户端持有父目录的caps，比如mkdir /test/a，caps就是客户端持有"test"目录的caps。客户端在发送mkdir请求时，会丢掉自己持有的"Fs"权限：客户端"test"的inode中caps为"pAsLsXsFs", 丢掉"Fs"，就是"pAsLsXs"。process_request_cap_release的代码简略如下。

void 

简单来讲就是将MDS缓存的"test"的CInode中的对应的客户端的caps与客户端保持一致，即cap中的_issued和_pending变成"pAsLsXs"。这样做的目的就是在acquire_lock时避免向该客户端发送revoke消息。

Server::handle_client_mkdir

cap_release消息处理完后，通过Server::dispatch_client_request分发请求，根据op执行Server::handle_client_mkdir，处理过程可以分为7个重要的流程：

1，获取"a"目录的CDentry以及需要加锁的元数据lock，具体函数为Server::rdlock_path_xlock_dentry

2，加锁，具体函数为Locker::acquire_locks，如果加锁不成功，即某些客户端持有的caps需要回收，就新建C_MDS_RetryRequest，加入"test"的CInode的waiting队列中，等待满足加锁条件后，再把请求拿出来处理。

3，如果加锁成功，则继续，新建"a"的CInode，具体函数为Server::prepare_new_inode

4，新建"a"的CDir，具体函数为CInode::get_or_open_dirfrag

5，更新"a"目录到"/"根目录的CDir和CInode中的元数据，填充"mkdir"事件，具体函数为MDCache::predirty_journal_parents

6，新建"a"的Capability，具体函数为Locker::issue_new_caps

7，记录"mkdir"事件，进行第一次回复，提交日志，具体函数为Server::journal_and_reply。

现在根据具体情况研究代码，代码如下

void 

Server::rdlock_path_xlock_dentry

该函数具体做的事如下

1，获取"a"的CDentry

2，填充rdlocks、wrlocks、xlocks

rdlocks："a"的CDentry中的lock

"/"、"test"的CInode的snaplocks（从根到父目录）

wrlocks："test"的CInode的filelock和nestlock

xlocks："a"的CDentry中的lock(simplelock)

代码如下

CDentry

在prepare_null_dentry函数中会新生成"a"的CDentry，代码如下

CDentry

即Server::prepare_null_dentry会先去父目录"test"的CDir的items中去找有没有"a"的CDentry，如果没有找到就新生成一个CDentry。研究MDS，不去研究元数据细节，很容易迷失。下面就是CDentry的类定义，其中可以看到CDentry是继承自LRUObject，因为CDentry是元数据缓存，得靠简单的LRU算法来平衡缓存空间。先研究其中的成员变量的含义

class 

接下来就是填充rdlocks，wrlocks，xlocks，然后根据填充的锁set数组，去拿锁，只有拿到需要的锁，才能去修改元数据。

Locker::acquire_locks

进行acquire_lock之前需要知道有哪些lock要去获取，如下

对"a"的CDentry的lock进行rdlock和xlock（这里有一个疑点，对lock加xlock后，其实就不需要再加rdlock，事实上接下来也只加了xlock），是因为在接下来会对"a"的CDentry里面的内容读写；对"a"的父目录"test"的filelock和nestlock加wrlock，是因为接下来要对"test"的CInode的inode里面的dirstat和neststat进行修改；对"test"的authlock加rdlock，是因为要读取"test"的权限相关的内容(mode、uid、gid等)；剩下的就是snaplock，这个与快照有关，这里暂不讨论快照。

这里解释下，为什么要加这些锁

1，对"test"的CInode的authlock加读锁，因为在Server::prepare_new_inode过程中会获取"test"的CInode的mode内容，如下

if 

2，对"test"的CInode的filelock和nestlock加wrlock，是因为之后在MDCache::predirty_journal_parents过程中会修改"test"的CInode中inode_t的dirstat和rstat：dirstat受filelock保护，rstat受nestlock保护。

3，对"a"的CDentry加xlock，是因为之后要去给CDentry中的linkage_t填充内容（CInode指针之类）

4，在之后也会去对CInode的versionlock加wrlock，是因为要去修改CInode中inode_t的version；对"/"的CInode的nestlock也加wrlock。

Locker::acquire_locks函数代码有好几百行，我把它分了3个步骤。

第一个步骤是整理xlocks、wrlock和rdlocks，因为这三个要加锁的set里面，可能有重复的lock，所以要把所有的lock放入一个整体的set中（sorted）。先遍历xlocks，将"a"的CDentry中的lock放入sorted中，将"a"的CDentry放入mustpin中，并且将"a"的CDentry的versionlock放入wrlocks中；接下来遍历wrlocks，将"a"的CDentry的versionlock和"test"的CInode的filelock和nestlock放入sorted中，并且将"test"的CInode放入mustpin中；遍历rdlocks，将"a"CDentry的lock，"test"CInode的authlock、snaplock，和"/"的CInode的snaplock放入sorted中，并将"/"的CInode加入mustpin中。代码如下

bool 

综上述得：所以sorted中有7个lock："a"的CDentry的lock和versionlock,"test"的CInode的filelock、nestlock、authlock、snaplock, 还有“/”目录的snaplock。

第二个步骤是auth_pin住元数据，通过第一步，可以知道要auth_pin的MDSCacheObject："a"的CDentry，"test"的CInode，"/"的CInode。先遍历这三个，去看看是否可以auth_pin，即判断两个部分：auth、pin。如果当前MDS持有的MDSCacheObject不是auth结点，则需要发给auth的MDS去auth_pin，如果当前的MDSCacheObject处于被冻结，或冻结中，则不能auth_pin，加入等待队列，等待可以auth_pin；然后直接返回false。如果可以auth_pin，下面才去auth_pin，将MDSCacheObject中的auth_pins++，代码如下

bool 

第三个步骤，正式开始加锁，经过一系列操作，要加锁的lock变化了，如下

wrlocks中多了"a"的CDentry的versionlock。sorted中有7个lock："a"的CDentry的versionlock和lock, “/”目录的snaplock，"test"的CInode的snaplock、filelock、authlock、nestlock。

bool 

开始遍历sorted。

• 对"a"的CDentry的versionlock加wrlock，看是否可以wrlock，即是否已经xlocked，这里可以直接加wrlock。并没有涉及到锁的切换。

bool 

• 对"a"的CDentry的lock加xlock，即进行xlock_start，最初锁的状态为LOCK_SYNC，而这种状态是不可以直接加xlock的，具体判断这里先不细讲，后面研究lock时，再扩展。

bool 

从simplelock数组中可以查的get_sm()->states[state].can_xlock == 0不满足xlock条件，所以要经过锁切换。先经过Locker::simple_lock，将锁的状态切换为LOCK_LOCK：LOCK_SYNC --> LOCK_SYNC_LOCK -->LOCK_LOCK。在LOCK_SYNC_LOCK -->LOCK_LOCK的切换过程中，需要判断是否满足条件：即该lock是否leased；是否被rdlocked；该CDentry是否在别的MDS上有副本，如果有，则需要发送LOCK_AC_LOCK消息给拥有副本的MDS，也去对它加锁。这里都满足，因为"a"目录是正在创建的。但是LOCK_LOCK也不能xlock，所以还需要继续切换，即通过Locker::simple_xlock，来切换锁：LOCK_LOCK --> LOCK_LOCK_XLOCK --> LOCK_PEXLOCK。切换成LOCK_PEXLOCK后就可以加xlock了。最后将锁状态切换为LOCK_XLOCK。

• 对"/"和"test"的CInode的snaplock加rdlock，它们锁的状态都是LOCK_SYNC，是可以直接加rdlock。这里没有涉及到锁的切换。
• 对"test"的CInode的filelock加wrlock，最初锁的状态为LOCK_SYNC，不满足加wrlock条件，需要通过Locker::simple_lock对锁进行切换。先将锁切换为中间状态LOCK_SYNC_LOCK，然后判断是否可以切换成LOCK_LOCK状态，在CInode::issued_caps_need_gather中，发现别的客户端拿了"test"目录inode的"Fs"权限（此时filelock的状态为LOCK_SYNC_LOCK，而这种状态的锁，只允许客户端持有"Fc"，其他与"F"有关的权限都不允许），所以"test"的CInode的filelock不能切换成LOCK_LOCK状态。需要通过Locker::issue_caps去收回其他客户端持有的"Fs"权限。

void 

issue_caps代码如下，即遍历"test"目录的CInode中client_caps中保存的各个客户端的Capability，此时通过get_caps_allowed_by_type算出客户端允许的caps为"pAsLsXsFc"，而有客户端持有"pAsLsXsFs"，所以发送CEPH_CAP_OP_REVOKE消息给客户端，让客户端释放"Fs"权限。

bool 

发送完revoke cap消息后，在Locker::wrlock_start中，跳出循环，生成 C_MDS_RetryRequest，加入等待队列，等待lock状态变成稳态后，再把请求拿出来执行。

bool 

接下来客户端会回复caps消息op为CEPH_CAP_OP_UPDATE。MDS通过Locker::handle_client_caps处理caps消息

Locker::handle_client_caps

代码如下

void 

在handle_client_caps中将客户端的cap中的_issued和_pending改变为"pAsLsXs"后，开始eval流程，分别eval_any "test"的CInode的filelock，authlock，linklock和xattrlock。

bool 

由于filelock的state为LOCK_SYNC_LOCK,不是稳态，所以去eval_gather, state状态的转换过程是LOCK_SYNC_LOCK --> LOCK_LOCK --> LOCK_LOCK_SYNC --> LOCK_SYNC，在mkdir的acquire_lock过程中，将LOCK_SYNC转换成LOCK_LOCK_SYNC，这里再将状态转换回来，转换成LOCK_SYNC。代码如下

void 

在eval_gather中只是将LOCK_SYNC_LOCK转换成LOCK_LOCK，在Locker::simple_sync中将lock转换为LOCK_SYNC, 代码如下

bool 

流程为

由于其他4个锁的状态都是LOCK_SYNC，不需要去转换状态，所以在eval_gather中并没有做实际的事情。接下来在finish_contexts中执行finishers中的回调函数，finishers存了之前的C_MDS_RetryRequest。即重新执行handle_client_mkdir

void 

流程为：

即重来一遍handle_client_mkdir，虽说是重来一遍，但由于之前request中保存了一些数据，所有有些过程不用重走。Server::rdlock_path_xlock_dentry与之前一样，就不重复分析，再来一遍Locker::acquire_locks

Locker::acquire_locks

之前讲了Locker::acquire_locks分为3个步骤：整理xlocks、wrlock和rdlocks；auth_pin住元数据；开始加锁。前两个步骤之前已经研究了，所以直接从第三个步骤开始。上一次是在对"test"的filelock加wrlock时，没加成功，所以这里直接从对"test"的filelock加wrlock开始。将锁切换为中间状态LOCK_SYNC_LOCK后，CInode::issued_caps_need_gather中并没有发现别的客户端拿了"test"目录inode的与"F"有关的权限，所以直接将lock的状态设为LOCK_LOCK。代码如下

void 

"test"的CInode的filelock状态为LOCK_LOCK时，就可以被加上wrlock了。加锁结束。

接下来是对"test"的CInode的authlock加rdlock。它的锁的状态是LOCK_SYNC，是可以直接加rdlock。这里没有涉及到锁的切换。

对"test"的CInode的nestlock加wrlock。而此时nestlock的状态已经是LOCK_LOCK，这个状态估计是之前的请求中加上的。可以直接加上wrlock。自此，acquire_lock过程完结。

总结：在acquire_lock中对7个lock（"a"的CDentry的versionlock和lock, “/”目录的snaplock，"test"的CInode的snaplock、filelock、authlock、nestlock）加锁。锁的状态变化如下图

接下来就是生成"a"目录的CInode，处理函数Server::prepare_new_inode，见下一篇。