ceph源码分析之读写操作流程（1）

ceph是一个存储集群，它拥有ceph-mon，ceph-mds和ceph-osd三种进程，本文主要从源码层面分析ceph-osd中的数据读写操作流程。

ceph-osd数据层级是这样的：

最上层：OSD，OSDServer

第二层：PG（具体实现类是ReplicatedPG）

第三层：ObjectStore(具体实现类是FileStore类，该类中有成员变量FileJournal类)

最底层：具体的Journal device或者file  （即系统读写函数）

介绍一下FileJournal，FileStore之间关系

ObjectStore定义了一个对象存储的抽象类

JournalingObjectStore继承ObjectStore定义了一个带有Journal的对象存储的类

Filestore最终继承成为一个实际工作的数据存储的类。

在JournalingObjectStore中定义了两个重要的成员变量：

Journal *journal   //指向了日志操作类Finisher finisher   //日志操作完成后的处理线程，在后面会提到

Journal定义了一个日志操作的抽象类

FileJournal继承Journal定义了一个实际工作的日志操作的类

两者之间的联系：OSD在init时，会new出一个FileStore类对象，并且在FileStore进行mount时候new出FileJournal类对象。

在第一层和第三层中拥有消息队列和执行线程，执行线程从消息队列中拿出数据来进行处理。

Finisher类是一个定义操作完成后的处理类，它内部自带了线程和消息队列。

OSD中处理读写操作是线程池和消息队列（有很多，其他暂时不讨论）：

ThreadPool  op_tp;ThreadPool::WorkQueueVal<pair<PGRef,OpRequestRef>, PGRef>  &op_wq;

FileJournal中拥有的线程和消息队列：

Write  write_thread;deque<write_item> writeq;

其父类Journal中拥有线程和消息队列（引用自之前说的JournalingObjectStore类中）：

Finisher        finisher_thread;

FileStore中拥有的线程和消息队列：

ThreadPool  op_tp;OpWQ        op_wq;//Filestore中实现，继承自ThreadPool::WorkQueue<OpSequencer>Finisher    ondisk_finisher;Finisher    op_finisher;

本章由于介绍的是上两层流程，故只用到了OSD::op_tp 和OSD::op_wq，在ceph源码分析之读写操作流程（2）文章中用到了上述的其他线程。

关于线程是如何具体工作的，可以参见ceph源码分析之线程介绍。

简单说一下线程池,所谓线程池就是根据配置文件中的配置，一次性创建了多个线程来处理消息队列中数据，它会轮询的处理在它之中的所有消息队列。即一个线程可能处理多个消息队列。

同时它定义了三种不同的WorkQueue,不同的WQ实现会在申明她们的类中自行实现需要的功能函数（如_process，_process_finish），线程从ThreadPool::worker为入口函数，开始等待op_wq中是否有数据，如果来了操作消息，则调用OSD::_process函数来执行。

为了方便，将数据操作分成两层来讲解，第一层是图1中的上两层，即数据操作的消息流程走向。第二层是图1中的下两层，即数据操作的实际读写流程。

在源码中，它们也被分别放在了osd和os两个文件夹中。

消息流程走向：

OSD获得消息后分发将消息送入了osd->op_wq队列。

void OSD::handle_op(OpRequestRef op){    ……    enqueue_op(pg,op);}

osd->op_tp线程从队列中拿出消息开始工作（op_tp线程是在OSD::init时创建，线程具体的工作在OSD::OpWQ::_process中）。

之后会调用到ReplicatePG::do_request，此函数根据不同的消息会选择不同的操作方案，关于操作主要有这三个：

void ReplicatedPG::do_request(OpRequestRef op,ThreadPool::TPHandle &handle){    ……    switch(op->get_req()->get_type()){    caseCEPH_MSG_OSD_OP:        ……        do_op(op);//1.主osd上的pg操作        break;    caseMSG_OSD_SUBOP:        do_sub_op(op);//2.从osd上的pg操作        break;    caseMSG_OSD_SUBOPREPLY:        do_sub_op_reply(op);//3.主osd接收到从osd上的pg操作返回        break;    ……    }}

然后分成了三步：

1.主osd：ReplicatedPG::do_opà ReplicatePG::execute_ctxà ReplicatedPG::prepare_transactionà ReplicatedPG::do_osd_ops

2.从osd：ReplicatedPG::do_sub_opàReplicatedPG::sub_op_modify写好后给主osd回应

3.主osd：ReplicatedPG::do_sub_op_replyà ReplicatedPG::sub_op_modify_reply-à ReplicatedPG::repop_ack-à ReplicatedPG::eval_repop

当第一步主osd调用ReplicatedPG::do_osd_ops处理完自己上面的pg操作后，会调用ReplicatedPG::issue_repop给副本pg的osd发消息。

于是第二步开始执行，从osd处理完后又会给主osd发送回应，

第三步开始执行，ReplicatedPG::eval_repop中会先通过ReplicatePG::waitfor_ack判断是否所有拥有pg的osd都回复了自己，

如果都回复了，则会调用OSD::sent_message_osd_client通知client端操作完成。

 

到此为止，关于读写操作的上层读写流程就已经完整了，再往后的调用就是ReplicatedPG层调用Filestore层的具体数据操作了。