【ceph】纠删码EC

纠删码EC

#define MSG_OSD_EC_WRITE       108
#define MSG_OSD_EC_WRITE_REPLY 109
#define MSG_OSD_EC_READ        110
#define MSG_OSD_EC_READ_REPLY  111

它们本身没有业务逻辑,作用是两件事:

  1. 发消息时打类型标签
    各消息类在构造时把自己标成对应类型,比如:

    • MOSDECSubOpWrite 用 MSG_OSD_EC_WRITE 
    • MOSDECSubOpWriteReply 用 MSG_OSD_EC_WRITE_REPLY 
    • MOSDECSubOpRead 用 MSG_OSD_EC_READ 
    • MOSDECSubOpReadReply 用 MSG_OSD_EC_READ_REPLY 
  2. 收消息时按类型反序列化和分发
    Message.cc 里会根据这个编号创建对应的消息对象:

    • 108 -> MOSDECSubOpWrite
    • 109 -> MOSDECSubOpWriteReply
    • 110 -> MOSDECSubOpRead
    • 111 -> MOSDECSubOpReadReply

然后 ECBackend::_handle_message() 再按这个 type 做业务分发:

 

  • MSG_OSD_EC_WRITE
    primary 发给各 shard OSD 的“子写请求”
    收到后走 handle_sub_write()
    发送点在 

  • MSG_OSD_EC_WRITE_REPLY
    shard OSD 回给 primary 的“子写完成回复”
    收到后走 handle_sub_write_reply()
    发送点在 

  • MSG_OSD_EC_READ
    primary 发给各 shard OSD 的“子读请求”
    用于客户端读、RMW 旧数据读取、恢复读取
    收到后走 handle_sub_read()
    发送点在 

  • MSG_OSD_EC_READ_REPLY
    shard OSD 回给 primary 的“子读回复”
    收到后走 handle_sub_read_reply()
    回复构造在 

你可以把它理解成 EC backend 自己内部的一套小 RPC 协议:

primary --MSG_OSD_EC_WRITE--> shard shard --MSG_OSD_EC_WRITE_REPLY--> primary primary --MSG_OSD_EC_READ--> shard shard --MSG_OSD_EC_READ_REPLY--> primary

所以一句话总结:

这 4 个宏就是 EC 子操作在 Ceph OSD 之间通信时用的消息类型编号,用来让 messenger 知道“这包是什么消息”,再让 ECBackend 知道“该走哪个处理函数”。

 

1. MSG_OSD_PG_RECOVERY_DELETE:

表示:primary 在 recovery/backfill 过程中,通知某个 peer OSD 删除一批对象。官方消息类注释都写了:instruct non-primary to remove some objects during recovery

位置在 

这个消息里最关键的字段是:

  • from
    谁发的
  • pgid
    目标 PG shard
  • objects
    要删除的对象列表,类型是 list<pair<hobject_t, eversion_t>>

也就是说它不是“删整个 PG”,而是:

删这个 PG 上的一批具体对象。

2. MSG_OSD_PG_RECOVERY_DELETE_REPLY

表示:

对端 OSD 把这些对象删完后,回给 primary 的确认消息。

定义在 

它会把:

  • from
  • pgid
  • objects

这些信息带回去,让 primary 知道“这些对象在这个 peer 上已经删掉了”。

posted @ 2026-04-22 17:08  苏格拉底的落泪  阅读(4)  评论(0)    收藏  举报