这个问题问得非常专业，而且你这个阶段问“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 状态：
activeclean
判断是 Primary
构造事务（transaction）
7️⃣ 构建 OSD Transaction（非常关键）
ObjectStore::Transaction t;t.write(object,offset,len,data);这是 Ceph 的“写原子操作单位”
8️⃣ 复制流程（Replicated Pool）
Primary OSD 会：
把写请求发给 Replica OSD：
issue_repop()自己也执行本地写
等待所有 Replica ACK
只有全部 ACK 才算写成功
五、BlueStore：真正落盘发生的地方
9️⃣ BlueStore 架构速览
BlueStore 由三部分组成：
| 组件 | 作用 |
|---|---|
| WAL | 写前日志（崩溃恢复） |
| RocksDB | 元数据 KV |
| Data Device | 实际数据 |
🔟 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实际发生了：
ext4 创建 inode
inode block → RBD object
RBD object → PG
PG → OSD.1 (Primary), OSD.2, OSD.3
三个 OSD：
- 写 WAL
- 写 RocksDB
- 写 data device
ACK 返回
shell 返回
八、为什么 RBD 写性能“看起来慢”但很安全？
因为它保证了：
- 多副本一致性
- 强一致写入
- crash-safe
- 分布式事务语义
这是它和本地磁盘最大的不同。
九、如果你愿意继续深入，我可以帮你：
- 🔍 把某个函数一路 trace 到 bdev aio_write
- 🔍 对比BlueStore vs FileStore
- 🔍 分析RBD cache / object-map / fast-diff 对写性能的影响
- 🔍 给你画一张“RBD 写入 + 源码路径对照表”
你下一步是想更偏源码，还是偏性能 / 调优视角？
