rbd写入的数据流

这个问题问得非常专业，而且你这个阶段问“RBD 写入的数据流，最好能到落盘，并结合代码”，已经是Ceph 原理 / 源码级理解了 👍
我下面按“从 write() 系统调用 → OSD 真正落盘”的顺序，逐层拆解，并在关键位置标出真实源码模块与函数名，让你能「对着源码看得懂」。

说明：以下分析基于Ceph Nautilus / Octopus / Quincy系列，核心路径一致。

一、整体视角：RBD 写入数据流（一句话版）

应用写数据 → 内核 / librbd → librados → Primary OSD → PG → BlueStore → WAL / RocksDB → 物理磁盘

我们先给一个分层总览，然后逐层下钻。

App ↓ write() VFS / FS (ext4) ↓ bio RBD (kernel) / librbd (user) ↓ librados ↓ OSD (Primary) ↓ PG ↓ BlueStore ↓ WAL / RocksDB + data device ↓ 磁盘落盘

二、客户端侧：write() 到 RBD（块 → 对象）

1️⃣ 应用层

write(fd,buf,len);

• 对应用来说，它在写“一块磁盘”

• 实际 fd 指向的是：

  • /dev/rbdX（内核方式）
  • /dev/nbdX（rbd-nbd）

2️⃣ 文件系统层（ext4 / xfs）

• ext4 把 write 拆成：

  • page cache
  • block I/O（bio）

最终形成：

structbio{sector_tbi_sector;void*data;size_tlen;}

3️⃣ RBD 客户端层（两种路径）

情况 A：内核 RBD（最常用）

关键模块：

drivers/block/rbd.c

关键函数链路（简化）：

rbd_queue_bio()→rbd_img_request_create()→rbd_obj_request_submit()

关键点：块 → 对象映射

RBD 会把逻辑块偏移转换为对象：

image offset: 0 ~ 4MB → rbd_data.00000000 image offset: 4 ~ 8MB → rbd_data.00000001

默认 object size = 4MB
对象名类似：rbd_data.<image_id>.<object_no>

情况 B：用户态 librbd（rbd-nbd / QEMU）

关键模块：

src/librbd/

核心类：

librbd::ImageCtx librbd::io::ImageRequest

写入路径（简化）：

ImageRequest::send()→ObjectDispatcher::dispatch()→ librados::IoCtx::write()

三、librados 层：对象写请求的“路由中心”

4️⃣ librados：从对象到 OSD

源码路径：

src/librados/

关键调用：

librados::IoCtx::write(object,bufferlist)

librados 做了三件关键事：

✅ 1. 从 MON 获取 OSDMap / PGMap

Objecter::_op_submit()

✅ 2. 计算 PG（CRUSH）

pg_t pgid=osdmap->object_locator_to_pg(object);

✅ 3. 选择 Primary OSD

osdmap->pg_to_up_acting_osds()

最终形成一个MOSDOp 消息：

MOSDOp{object=rbd_data.xxx op=WRITE offset,length}

四、OSD 层：真正“写数据”的地方（重点）

5️⃣ Primary OSD 接收写请求

源码路径：

src/osd/OSD.cc

入口函数：

OSD::handle_op(MOSDOp*op)

6️⃣ PG 层：一致性与复制控制

路径：

src/osd/PrimaryLogPG.cc

关键函数：

PrimaryLogPG::do_op()

在这里：

• 检查 PG 状态：

  • active
  • clean

• 判断是 Primary

• 构造事务（transaction）

7️⃣ 构建 OSD Transaction（非常关键）

ObjectStore::Transaction t;t.write(object,offset,len,data);

这是 Ceph 的“写原子操作单位”

8️⃣ 复制流程（Replicated Pool）

Primary OSD 会：

1. 把写请求发给 Replica OSD：

   issue_repop()

2. 自己也执行本地写

3. 等待所有 Replica ACK

只有全部 ACK 才算写成功

五、BlueStore：真正落盘发生的地方

9️⃣ BlueStore 架构速览

BlueStore 由三部分组成：

🔟 BlueStore 写路径（重点）

源码路径：

src/os/bluestore/BlueStore.cc

关键函数：

BlueStore::_do_write()

内部流程（简化）：

① 写 WAL（顺序写）

BlueStore::submit_transaction()

• 先写 WAL
• 保证 crash-safe

② 更新 RocksDB（元数据）

db->Put(object_key,extent_map)

记录：

• 对象 → 物理块映射
• 校验信息

③ 写 Data Device（真正的数据）

bdev->aio_write(offset,data)

这里才是：

数据真正写到磁盘（SSD / HDD / NVMe）

④ fsync / aio flush

• WAL 持久化
• Data IO 完成
• 标记 transaction committed

11️⃣ ACK 返回链路（反向）

Disk ↑ BlueStore ↑ OSD ↑ Primary OSD ↑ librados ↑ librbd / kernel rbd ↑ FS ↑ write() 返回

六、写成功的“严格定义”

一个 RBD write 返回成功，意味着：

✔ Primary OSD 写成功
✔ 所有 Replica OSD 写成功
✔ WAL 已落盘
✔ 元数据已持久化

不是只是进了 cache。

七、结合一个“写一行文本”的真实例子

echo"hello ceph">/mnt/rbd/data.txt

实际发生了：

1. ext4 创建 inode

2. inode block → RBD object

3. RBD object → PG

4. PG → OSD.1 (Primary), OSD.2, OSD.3

5. 三个 OSD：

   • 写 WAL
   • 写 RocksDB
   • 写 data device

6. ACK 返回

7. shell 返回

八、为什么 RBD 写性能“看起来慢”但很安全？

因为它保证了：

• 多副本一致性
• 强一致写入
• crash-safe
• 分布式事务语义

这是它和本地磁盘最大的不同。

九、如果你愿意继续深入，我可以帮你：

• 🔍 把某个函数一路 trace 到 bdev aio_write
• 🔍 对比BlueStore vs FileStore
• 🔍 分析RBD cache / object-map / fast-diff 对写性能的影响
• 🔍 给你画一张“RBD 写入 + 源码路径对照表”

你下一步是想更偏源码，还是偏性能 / 调优视角？