Ceph on Mer's Blog

Ceph-读写流程：客户端写流程分析(二)

Mon, 29 May 2023 03:36:46 +0000

本文接上文对 Filer::write_trunc 及之后的流程做了梳理和总结.

正文

本文是 Ceph 读写流程：客户端写流程分析的后续，前文包括 ll_open 和 ll_write 的处理流程。

Client 通过 Filer::write_trunc 写文件时会做两件事：通过 Striper::file_to_extents 做一次客户端条带化，将要写入的部分转换为对象的 extent 集合；接着通过 objecter->sg_write_trunc 进行写入

void write_trunc (...)
{
 vector<ObjectExtent> extents;
 Striper::file_to_extents(cct, ino, layout, offset, len, truncate_size,
			 extents);
 objecter->sg_write_trunc(extents, snapc, bl, mtime, flags,
		 truncate_size, truncate_seq, oncommit, op_flags);
}

而在 sg_write_trunc 中，objecter 会向每个 ObjectExtent 对应的 OSD 发送 op 请求，这里通过 write_trunc 完成，考虑 extents.size() == 1 的情况如下：

Ceph-Fuse Perms heap-buffer-overflow 问题

Sun, 23 Apr 2023 08:20:53 +0000

Ceph-fuse 带 Address-Sanitizer 跑发现只要 MDS 切换就会导致客户端 heap-buffer-overflow (ASAN 信息附在最后)

问题分析

带 debuginfo 的情况下 ASAN 报的信息还是比较全的，说踩内存的地方在 src/messages/MClientRequest.h:151 的 MClientRequest::set_gid_list 函数中，并且指出这里尝试读了一个野指针，看下 MClientRequest::set_gid_list 函数这里的行为：

	void set_gid_list(int count, const gid_t *gids) {
		gid_list.reserve(count);
		for (int i = 0; i < count; ++i) {
→ gid_list.push_back(gids[i]);
		}
	}

可以看到这里问题就在 gids 上，看一下这个指针是哪里传进来的：

Ceph MDS InodeTable 分配流程和故障分析

Fri, 14 Apr 2023 00:33:43 +0000

本文对 Ceph 中 inode 分配流程进行了总结，并解释了 MDS 重启过程中可能遇到的一个故障

inode 分配流程

在 Ceph 中我们创建目录、文件、软链接时都需要为其分配一个 inode 作为唯一标识，这一分配过程在 Server::prepare_new_inode 中完成，而分配的依据，也就是哪些 inode 还没有被分配，哪些
被分配了还没有生效（落盘）则是记录在 InoTable 中:

class InoTable : public MDSTable {
...
private:
 interval_set<inodeno_t> free; // unused ids
 interval_set<inodeno_t> projected_free;
...

其中 free 记录的就是没有被分配的 inode 集合，而 projected_free 则是从 free 中剔除了已经被分配但是还没有落盘的部分，因此 projected_free 是 free 的子集，同时显然分配也首先要在 projected_free 中来做。

Ceph MDS MetaBlob 分析

Thu, 06 Apr 2023 07:28:29 +0000

CephFS 中会把多种事件记录在不同类型的 LogEvent 中，其中最常见的也是最重要的就是读写流程中处理客户端请求时记录的 EUpdate 事件，而在 EUpdate 中又会把元数据的状态保存在 MetaBlob 结构中，本文就主要对 MetaBlob 结构以及其中保存的内容做一个总结。

MetaBlob 类定义看上去比较复杂，实际最重要的成员只有三个：

class EMetaBlob {

public:
 // my lumps. preserve the order we added them in a list.
 std::vector<dirfrag_t> lump_order;
 std::map<dirfrag_t, dirlump> lump_map;
 std::list<fullbit> roots;

其中 lump_order 保存从根目录到父母路的 Dir 分片信息 dirfrag_t，lump_map 中保存 dirfrag_t 到 dirlump 的映射关系， dirlump 中保存的就是相关的元数据信息，最后 roots 保存的就是 root 节点的 fullbit 信息，fullbit 表示一个存在的 dn + inode，相对的 MetaBlob 中使用 null_bit 结构保存一个不存在的 dentry

Paxos 算法以及 Ceph 实现

Wed, 05 Apr 2023 14:57:58 +0000

本文包含 Paxos、Multi-Paxos 算法的原理以及 Ceph 中对 Paxos 算法的实现。

Basic Paxos 和 Multi-Paxos

Paxos 和 raft 算法看过不少次，但是始终属于一知半解，也没有个记录，这次把 Paxos 和 Multi-Paxos 的原理和 ceph 中 Paxos 的实现都记录一下：

首先是 Paxos 算法，朴素的 Paxos 算法是不包含 leader 角色的：

proposer (提议者): 提出提案，包含提案编号（proposal ID）和一个要协商的值（Val）
acceptor (决策者)：参与决策，回应收到的来自 proposer 的提案，当多数 acceptor 赞成时提案通过，一般来说一个 proposer 同时也是一个 acceptor

Basic Paxos 算法通过两阶段通过一个决议：

Ceph 读写流程：客户端写流程分析

Sat, 01 Apr 2023 10:01:16 +0000

本文对 Ceph 客户端写流程进行了梳理和总结，包括 ll_open 和 ll_write 的处理流程。

正文

首先用户需要通过 ll_open 打开文件并拿到 fh，第一步先做权限检查，进入 may_open, 这里会根据用户带回的 flags 确定 want 是 MAY_WRITE 还是 MAY_READ, 接着通过一次 getattr 拿到文件的 mode, 当然这里 getattr 不是每次都发，只有 client 认为自己的所持有的文件权限不是最新的时候才会发，具体有两种情况：

开启 acl 并且没有拿过文件的 xattr (acl 设置是外带在 xattr 中的，不在 inode 里)
caps_issued_mask 认为当前 client 的 caps 不足以保证所持有的权限为最新时

Client::_getattr 判断是否需要发送请求

int Client::_getattr(Inode *in, int mask, const UserPerm& perms, bool force)
{
 bool yes = in->caps_issued_mask(mask, true);

 if (yes && !force)
 return 0;
...
// force 和 mask:
int Client::_getattr_for_perm(Inode *in, const UserPerm& perms)
{
 int mask = CEPH_STAT_CAP_MODE;
 bool force = false;
 if (acl_type != NO_ACL) {
 mask |= CEPH_STAT_CAP_XATTR;
 force = in->xattr_version == 0;
 }
 return _getattr(in, mask, perms, force);
}

简单解释一下第二点就是如果 client 没有持有 As （开启 acl 的话还需要 Xs）那么就需要向 mds 发 getattr
拿到 perm 之后做一个 inode_permission 检查一下 mode (如果设了 acl 那就检查 acl)

Ceph 读写流程：file_to_extents 过程分析

Thu, 30 Mar 2023 06:02:08 +0000

本文介绍 Ceph 中条带化的相关概念并对 Striper::file_to_extents 的流程进行了分析和总结。

在 Client::_write 中客户端通过 filer->write_trunc 对文件进行写入，write_trunc 其中分为两步:

通过 Striper::file_to_extents 对请求进行拆分，也就是将对文件的读写请求转换为对对象的读写请求
通过 objecter->sg_write_trunc 把数据写到 object 中

本文主要对其中的第一步，也就是 Striper::file_to_extents 的过程进行分析。

Ceph 中的 Stripping

在正式开始先简单介绍一下 Ceph 中条带化（Stripping）读写的相关概念：

为什么要使用 Stripping

最主要的原因就是由于单个存储设备存在吞吐量限制，例如一块机械硬盘的写入能力最大也不过 200MB/s, 在与内存、固态缓存甚至是万兆网络的吞吐量对比下无疑就是整个系统中最大的短板，那么条带化就是用来解决存储设备性能瓶颈，提高存储系统吞吐量的东西。

那么什么是条带化，说的准确一点就是把信息的连续部分存储在多个存储设备上，说人话就是把一个文件切成多份放在不同的磁盘上，每次对文件中一段内容的读写会同时发给多个盘，这样的话我们实际的写入速度就变成了多个磁盘的写入速度总和。

Ceph 中的条带化的概念大致和其他存储没有区别，只不过在 Ceph 中所有的存储最后都会落到 object 也就是对象上，而对象的存储是没有条带化的，因此文件的条带化实际上是在客户端上进行的，也就是我们本文的主要内容 file_to_extents 的过程

Ceph 挂载点压缩提示 File changed as we read it 问题分析

Mon, 27 Mar 2023 06:50:07 +0000

使用 CephFS 的同学可能会发现如果在 CephFS 挂载点下去压缩文件的时候有时候会提示 File changed as we read it，有时候还会导致
CRC 失败，本文对 File changed as we read it 问题出现的原因进行了分析并给出了解决办法，希望能对大家有所帮助。

问题现象

首先这个问题可能导致的现象比较多样，最基础的就是把一个压缩文件解压一下然后立马压缩，这时就会提示 File changed as we read it 如下：

[root@An1Uit ceph-fuse]# ./tar.sh
tar: cmake-3.7.2/Tests/LinkFlags: 在我们读入文件时文件发生了变化
tar: cmake-3.7.2/Tests/SimpleCOnly: 在我们读入文件时文件发生了变化
tar: cmake-3.7.2/Tests/ObjC++: 在我们读入文件时文件发生了变化

那除了这个现象以外还可能导致一些应用的 CRC 校验失败，或者 nfs 的 REMOTE I/O ERROR

Ceph MDS Stuck in Client Replay 问题分析

Sun, 26 Mar 2023 04:34:54 +0000

最近一直在做 MDS 高可用方面的工作，发现 MDS （带 IO）重启时可能会长时间卡在 Client Replay 状态。这里对问题的原因做了一下分析，并给出了现有的以及未来的解决办法，希望能对大家有所帮助。

问题现象梳理

通过 ceph -s 看到 MDS 的状态长时间在 client replay 状态不变化：

[root@node2 ~]# ceph -s
 cluster:
 ...
 mds: cephfs: 1/1 {0=node2=up:clientreplay}

查看 MDS 状态会发现 clientreplay_queue 不为空，但是如果打开 MDS 日志会发现 MDS 什么都没做（除了心跳）：

Ceph Client 中的 LRU 设计

Wed, 08 Mar 2023 13:38:20 +0000

在 Ceph 中 Client 和 MDS 部分的 lru 实现和淘汰策略稍有不同，但作用都是用来管理 dentry 等结构，方便及时将不使用的文件和目录清出内存，这里主要关注 lru 的实现而不关注 dentry 的淘汰时机。

首先看下 LRU 的结构：

// lru.h
class LRU {
// ...
private:
 using LRUList = xlist<LRUObject*>;
 LRUList top, bottom, pintail;
}

这里和大部分 LRU 的实现类似， ceph 也使用一个双向链表作为 lru 的基础结构（也就是这里的 xlist，基本可以当作一个双向链表看待）。只不过 ceph 同时使用了三个链表 top、bottom 和 pintail 来细化 lru 的不同位置。