消息封装
在OSD上发送和接收信息。有两类:
1.cluster_messenger -与其它OSDs和monitors沟通
2.client_messenger -与客户端沟通
消息调度
Dispatcher类,主要负责消息分类
工作队列
1. OpWQ: 处理ops(从客户端)和sub ops(从其他的OSD)。运行在op_tp线程池。
2. PeeringWQ: 处理peering任务,运行在op_tp线程池。
3. CommandWQ:处理cmd命令,运行在command_tp。
4. RecoveryWQ: 数据修复,运行在recovery_tp。
5. SnapTrimWQ: 快照相关,运行在disk_tp。
6. ScrubWQ: scrub,运行在disk_tp。
7. ScrubFinalizeWQ: scrub,运行在disk_tp。
8. RepScrubWQ: scrub,运行在disk_tp。
9. RemoveWQ: 删除旧的pg目录。运行在disk_tp。
线程池
有4种 OSD线程池:
1. op_tp: 处理ops和sub ops
2. recovery_tp:处理修复任务
3. disk_tp: 处理磁盘密集型任务
4. command_tp: 处理命令
注:索引的格式,查找更新索引、如何持久化的,还没搞清楚。
没有所谓索引,一切皆规则:
每个object的文件名格式为:
objectname_key_head(snap_num)_hash_namespace_poolid
Ø objectname:对象名
Ø key、namespace:都是客户端指定,做名称空间细分用。当块儿设备使用时,一般都置为空
Ø head(snap_num):snapshot版本
Ø hash:由objectname计算得到,u_int32_t类型,这里转换为16进制字符打印,如3AF0B980
Ø poolid:pool的id
目录结构:
数据目录/PG名称/子目录/object文件名
举例说明:
/data09/ceph/osd2/current/0.0_head/DIR_0/DIR_8/DIR_9/10000007af4.00000000__head_3AF0B980__0
其中,子目录是根据object文件名中hash字段的字符反向排列生成。当一个目录中的文件个数大于配置值(merge_threshold * 16 * split_multiplier)时,会建子目录,对文件进行归档。
ReplicatedPG.h
ReplicatedPG.cc
int ReplicatedPG::do_osd_ops(OpContext *ctx, vector<OSDOp>& ops)函数中的
Case CEPH_OSD_OP_READ分支
r = osd->store->fiemap(coll, soid, op.extent.offset, op.extent.length, bl);
r = pgbackend->objects_read_sync(
soid, miter->first, miter->second, &tmpbl);
pgbackend->objects_read_sync转int ReplicatedBackend::objects_read_sync调用 store->read(coll, hoid, off, len, *bl) ,来自ObjectStore::read
阶段1:主节点发请求
阶段2:从节点处理请求
osd->store->queue_transactions(&osr, rm->tls, onapply, oncommit);
这里注册的两个回调:
Context *oncommit = new C_OSD_RepModifyCommit(rm); 当日志写入磁盘后被调用
Context *onapply = new C_OSD_RepModifyApply(rm); 当该操作被处理后被调用
分别向主节点做ACK和ON_DISK两种回应。
注:transaction封装,journal log写入细节,对象写入细节还没来得及看。
阶段3:主节点接收从节点回应,并回应客户端