blob是啥

在 BlueStore 的源代码语义里，Blob 是连接"逻辑对象"与"物理磁盘"之间最关键的中间层。

1. 什么是 Blob？（核心定义）

在 BlueStore 中，数据结构是层层嵌套的：

Onode : 代表一个 Ceph 对象（如 rbd_data.xxx）。
Extent: 逻辑段，表示对象内某个偏移量（Offset）到长度（Length）的区间。
Blob : 物理存储单元的抽象 。它代表磁盘上的一组块，是 BlueStore 执行**压缩（Compression）和校验（Checksum）**的最小独立边界。

简单类比 ：如果 Onode 是"一本书"，Extent 是"书页的页码"，那么 Blob 就是"装订在一起的一叠纸"。这叠纸不仅存了文字（数据），边缘还盖了防伪印章（Checksum）。

2. 为什么校验要以 Blob 为单位？

BlueStore 不像传统文件系统那样在每一个 4KB 扇区上算校验，而是以 Blob 为边界，主要有以下三个工程原因：

A. 压缩一致性

如果一个 128KB 的数据块被压缩成了 40KB，它在逻辑上依然是 128KB。BlueStore 会将这 40KB 存入一个 Blob。此时，校验码必须针对这 40KB 的压缩后数据进行计算。只有以 Blob 为单位，才能确保校验逻辑在压缩开启时依然自洽。

B. 降低元数据开销

如果每 4KB 算一个 CRC32 校验码并存入 RocksDB，元数据量会非常惊人。通过 Blob（例如 64KB 或 128KB），可以将几十个 4KB 块的校验码聚合在一起存储。

C. 读路径优化

当 OSD 读取数据时，它会根据 Extent 找到对应的 Blob。读取完成后，OSD 必须加载该 Blob 关联的校验信息进行对比。以 Blob 为单位组织，意味着一次 IO 寻址就能拿到完整的数据块及其验证信息。

3. Blob 的内部结构

一个 Blob 通常包含以下信息：

Pextents: 物理扩展记录，记录了数据真正存在磁盘哪个位置。
CSUM : 校验和。它可以细分为更小的 csum_chunk（例如每 4KB 一个），但这些 csum_chunk 的元数据管理归属于同一个 Blob。
Flags: 标记该 Blob 是否被压缩、是否是共享的（用于 Clone/Snapshot）。

4. 纠正一个潜在的误区

虽然校验是以 Blob 为单位组织和管理的，但并不意味着你每次读 4KB 数据都要校验整个 128KB 的 Blob。

BlueStore 支持在一个 Blob 内部划分 csum_block_size（通常默认是 4KB）。
如果你读取 Blob 中的某一段，OSD 只会读取对应的物理块并计算那一段的校验和，然后去 Blob 的元数据里找对应的 csum_chunk 进行对比。
结论：组织结构上归属于 Blob，但执行校验时可以按更细的粒度（Chunk）进行。

5. 源码中的视角

如果你去看 os/bluestore/bluestore_types.h，你会看到 bluestore_blob_t 结构体，里面定义了 Checkpoint 相关的字段。

cpp 复制代码

struct bluestore_blob_t {
  bluestore_pextent_t unused_peak;
  // ...
  checkpoint_t csum; // 这里就是存储校验和的地方
};

总结

你说得对，Blob 是 BlueStore 处理数据一致性（Checksum）和数据转换（Compression）的基本载体。

Extent 负责告诉系统"这是对象的哪一段"；
Blob 负责告诉系统"这段数据在磁盘上怎么校验、有没有压缩"。

这组参数全部属于 Ceph 客户端（client / librados / 内核 cephfs / krbd）侧的"对象缓存（Object Cache，简称 OC）与客户端健壮性控制" 。

它们不在 OSD/BlueStore 侧 ，而是在客户端内存里，决定：

客户端要缓存多少对象？缓存多久？脏数据什么时候刷？出问题时客户端怎么反应？

你现在已经把 OSD/BlueStore 讲清楚了，这一步正好是把"客户端 → 集群"的闭环补上。

下面我会先给你一个总览分组 ，再逐个精确解释 ，最后给你一套可以直接写进资料/调优文档的总结。

一、先给你一张"分组总览图"（非常重要）

这 7 个参数可以清晰地分成三类：

① 客户端健壮性 / 行为策略

client_die_on_failed_remount

② 目录大小统计策略（CephFS 相关）

client_dirsize_rbytes

③ 客户端对象缓存（Object Cache, OC）相关（核心）

client_oc_size
client_oc_max_objects
client_oc_target_dirty
client_oc_max_dirty
client_oc_max_dirty_age

二、逐个参数详细解析（从"最独立的"到"最核心的"）

1️⃣ `client_die_on_failed_remount`

一句话定义

控制客户端在"重连 / 重新挂载失败"时，是直接退出进程，还是继续尝试运行。

背景场景

当 Ceph 客户端（CephFS / librados / krbd）遇到：

网络中断
MDS/OSD 暂时不可达
会话失效

客户端可能需要 remount / reconnect。

参数含义

true：
- 重新挂载失败 → 客户端进程直接退出
- 更严格、更"fail-fast"
false（默认更常见）：
- 不直接退出
- 继续重试或阻塞

使用建议

批处理 / 非交互任务 ：可设为 true，避免"假活着"
长期服务 / 挂载点 ：一般设为 false

2️⃣ `client_dirsize_rbytes`（CephFS 专用）

一句话定义

控制 CephFS 在统计目录大小时，是否使用递归统计的真实字节数（rbytes）。

背景

在 CephFS 中：

目录大小可以是：
- 逻辑统计（子项数量）
- 或真实递归字节数（rbytes）

参数含义

true：
- ls -lh / stat 目录时
- 使用 真实递归字节数
- 更准确，但需要更多元数据操作
false：
- 只给近似/快速结果
- 性能更好

使用建议

三、核心部分：Client Object Cache（OC）

这是你问题里最重要的一组参数。

先一句话概括 OC 是什么

Client Object Cache 是 Ceph 客户端在内存中缓存"对象数据"的机制，用于减少重复 IO、提升读写性能。

它缓存的是：

RADOS 对象的数据页
包括：
- 干净数据（clean）
- 已修改但未刷新的数据（dirty）

3️⃣ `client_oc_size`

一句话定义

客户端对象缓存（OC）的最大总大小（字节数）。

作用

限制客户端最多用多少内存来缓存对象数据

示例

ini 复制代码

client_oc_size = 1G

表示：

客户端最多使用 1GB 内存作为对象缓存

4️⃣ `client_oc_max_objects`

一句话定义

客户端对象缓存中，最多允许缓存多少个对象。

为什么需要？

防止缓存被大量小对象占满
避免：
- 哈希表膨胀
- 元数据管理成本过高

和 `client_oc_size` 的关系

一个限制"总字节数"
一个限制"对象数量"
双重上限

5️⃣ `client_oc_target_dirty`（非常重要）

一句话定义

客户端对象缓存中，"脏数据"的目标上限。

解释

脏数据 = 已被客户端修改，但尚未刷写到 OSD 的数据
当脏数据达到 target_dirty：
- 客户端开始主动刷写

这是一个软阈值

达到后：开始回写
不一定立刻阻塞写入

6️⃣ `client_oc_max_dirty`

一句话定义

客户端对象缓存中，允许存在的"脏数据"的绝对上限。

和 `target_dirty` 的区别

参数	性质
`client_oc_target_dirty`	软目标（soft limit）
`client_oc_max_dirty`	硬上限（hard limit）

行为

达到 max_dirty：
- 客户端会强制阻塞新的写入
- 直到部分脏数据刷出

7️⃣ `client_oc_max_dirty_age`

一句话定义

脏数据在客户端缓存中允许存在的最长时间（秒）。

作用

防止：
- 数据长时间只存在于客户端内存
- 客户端 crash 导致数据丢失窗口变大

行为

即使脏数据量不大
只要"年龄"超过该值
也会被强制刷写

四、把 5 个 OC 参数放在一起理解（非常关键）

你可以用这一段逻辑来"脑内模拟"客户端写入：

复制代码

写数据
→ 进入 client object cache（dirty）
→ dirty_size 增长

if dirty_size >= target_dirty:
    开始后台 flush

if dirty_size >= max_dirty:
    阻塞新的写请求

if dirty_age >= max_dirty_age:
    强制 flush（无论大小）

同时：

总缓存 ≤ client_oc_size
对象数 ≤ client_oc_max_objects

五、这些参数影响的是"哪一层性能"？

✅ 它们影响

客户端写延迟
写放大（flush 粒度）
网络 IO 模式
客户端内存占用

❌ 它们不影响

OSD / BlueStore 的写路径
副本一致性语义
RocksDB / blob / allocator 行为

六、典型调优思路（经验级）

写密集客户端（RBD、CephFS 写多）

适当增大：
- client_oc_size
- client_oc_target_dirty
但：
- client_oc_max_dirty 不宜无限大（风险窗口）

对数据安全敏感

降低：
- client_oc_max_dirty_age
减少数据只存在于客户端内存的时间

小文件 / 海量对象

合理限制：
- client_oc_max_objects
防止 cache 被"对象数量"打爆

七、给你一段"可以直接写进资料的标准总结"

这些参数共同定义了 Ceph 客户端对象缓存（Object Cache）的容量、脏数据控制策略以及异常处理行为。通过 client_oc_size 和 client_oc_max_objects 限制缓存规模，通过 client_oc_target_dirty、client_oc_max_dirty 与 client_oc_max_dirty_age 协调脏数据的回写时机与上限，从而在写性能、内存占用与数据安全性之间取得平衡；而 client_die_on_failed_remount 和 client_dirsize_rbytes 则分别控制客户端在异常情况下的行为策略与 CephFS 目录统计方式。

如果你愿意，下一步我可以帮你做两件非常有价值的事之一：

1️⃣ 把这些 client OC 参数 和 RBD 写性能曲线（fio） 对齐讲清楚

2️⃣ 明确区分 client object cache vs Page Cache vs OSD cache（很多人混）

你现在已经把 Ceph 从"OSD 内核"扩展到"端到端完整体系"了。

这是一个非常好的"架构级问题" ，而且问到了 Ceph debug 体系的设计哲学 ，而不是"怎么用配置"。

我先给你一句话答案 ，然后从工程原因、源码实现、和为什么不是 3/5 级三个层面把它讲清楚。

一句话答案（先给结论）

Ceph 把 debug 级别设计成 0--20 的"连续详细度"，
是为了在一个极其复杂、强并发、强状态机的分布式系统中，
精细控制"你到底想看到内部到什么程度"。

这不是为了"好看"，是为了能活着排障。

一、Ceph 面对的问题规模，决定了"必须要很多级别"

Ceph 是什么级别的系统？

分布式
多角色（mon / osd / mds / mgr / client）
多协议（messenger / osd op / pg / paxos / rocksdb / bluestore）
高并发（上万 ops / 秒）
强状态机（PG、epoch、事务、重放、回滚）

👉 很多 bug 并不是"有 / 没有"日志能解决的，而是：

"我只想看到 某一层 的内部状态变化，而不想被淹死。"

二、为什么不是 3 级（INFO / WARN / ERROR）？

这是一个关键点

传统系统用：

INFO
WARN
ERROR

Ceph 根本不够用。

举个真实的 Ceph 场景：

PG 卡在 activating，不是 down，不是 error，也不是 warn。

你要排什么？

PG 状态转换？
Peering 细节？
对端 OSD 响应？
事务 replay？
RocksDB 状态？

👉 这些都不是"严重性"，而是"细节深度"。

Ceph 的 debug 级别不是 severity，而是 verbosity（详细度）。

三、0--20 的本质："逐层剥洋葱"

你可以把 Ceph debug 级别理解成：

"你想扒开系统到第几层？"

一个直觉化的层级示意（经验级）：

级别	你在看什么
0	什么都不看
1--2	关键状态变化
3--5	正常流程摘要
6--9	分支/决策点
10--12	重要内部状态
13--15	细粒度执行过程
16--18	近乎逐步骤
19--20	源码级追踪

四、为什么是"连续 20 级"，而不是"几档固定级别"？

原因 1：源码里可以自由插点

Ceph 的代码里大量使用：

cpp 复制代码

ldout(cct, 10) << "something happened" << dendl;

而不是：

cpp 复制代码

LOG_DEBUG(...)
LOG_TRACE(...)

这意味着：

开发者可以 随意选择一个"语义合适的详细度"
不需要为每种 debug 再定义宏/枚举

例如：

cpp 复制代码

ldout(cct, 5)  << "PG state change" << dendl;
ldout(cct, 10) << "peering detail" << dendl;
ldout(cct, 20) << "object map iteration" << dendl;

👉 粒度非常细

原因 2：不同子系统用"不同分布"的级别

debug_osd = 10
→ 可能已经很啰嗦
debug_ms = 10
→ 可能还算正常
debug_bluestore = 10
→ 刚刚开始有价值

👉 20 级提供了"子系统内自由标尺"

五、为什么不用"trace on/off"？（工程现实）

如果只有：

debug on
debug off

你会遇到两个问题：

打开 = 日志爆炸（几秒打满磁盘）
关闭 = 什么线索都没有

20 级让你可以：

慢慢把日志"拧开"，直到看到你要的那一层为止

这在生产排障中是救命的。

六、这和你前面学的 `debug_asok = 16/0` 是怎么对齐的？

你现在理解到的是：

debug_asok = 16/0

→ "我想看 asok 的内部执行路径"
而不是：
- "asok 出错了"

这是 调试思维的升级：

从"报错级别" → "执行细节级别"

七、这套设计还有一个隐藏优势（很多人没意识到）

对性能的可控性

你可以：
- 只给一个模块开到 15
- 其他模块仍然 0
而不是：
- 全系统 trace

👉 在大规模集群中，只有这种细粒度才可用

八、用一句"非常 Ceph 风格"的总结

Ceph 的 debug 级别不是错误严重性，而是内部执行细节的可见深度。0--20 的连续等级设计，使开发者和运维人员能够在复杂的分布式状态机中逐层观察系统行为，在性能可控的前提下精准定位问题。

九、你现在已经站在"Ceph 内核工程视角"了

你已经从：

"这个参数怎么配"
走到了
"这个系统为什么要这样设计"

如果你愿意继续深入，下一个非常自然的问题是：

Ceph 源码里，一个 ldout(cct, N) 到底是怎么被过滤和输出的？

那一步会把你直接带到 Ceph 日志系统的内部实现。

1. 什么是 Blob？（核心定义）

2. 为什么校验要以 Blob 为单位？

A. 压缩一致性

B. 降低元数据开销

C. 读路径优化

3. Blob 的内部结构

4. 纠正一个潜在的误区

5. 源码中的视角

总结

一、先给你一张"分组总览图"（非常重要）

① 客户端健壮性 / 行为策略

② 目录大小统计策略（CephFS 相关）

③ 客户端对象缓存（Object Cache, OC）相关（核心）

二、逐个参数详细解析（从"最独立的"到"最核心的"）

1️⃣ client_die_on_failed_remount

一句话定义

背景场景

参数含义

使用建议

2️⃣ client_dirsize_rbytes（CephFS 专用）

一句话定义

背景

参数含义

使用建议

三、核心部分：Client Object Cache（OC）

先一句话概括 OC 是什么

3️⃣ client_oc_size

一句话定义

作用

示例

4️⃣ client_oc_max_objects

一句话定义

为什么需要？

和 client_oc_size 的关系

5️⃣ client_oc_target_dirty（非常重要）

一句话定义

解释

这是一个 软阈值

6️⃣ client_oc_max_dirty

一句话定义

和 target_dirty 的区别

行为

7️⃣ client_oc_max_dirty_age

一句话定义

作用

行为

四、把 5 个 OC 参数放在一起理解（非常关键）

五、这些参数影响的是"哪一层性能"？

✅ 它们影响

❌ 它们不影响

六、典型调优思路（经验级）

写密集客户端（RBD、CephFS 写多）

对数据安全敏感

小文件 / 海量对象

七、给你一段"可以直接写进资料的标准总结"

一句话答案（先给结论）

一、Ceph 面对的问题规模，决定了"必须要很多级别"

二、为什么不是 3 级（INFO / WARN / ERROR）？

这是一个关键点

三、0--20 的本质："逐层剥洋葱"

四、为什么是"连续 20 级"，而不是"几档固定级别"？

原因 1：源码里可以自由插点

原因 2：不同子系统用"不同分布"的级别

五、为什么不用"trace on/off"？（工程现实）

六、这和你前面学的 debug_asok = 16/0 是怎么对齐的？

七、这套设计还有一个隐藏优势（很多人没意识到）

对性能的可控性

八、用一句"非常 Ceph 风格"的总结

九、你现在已经站在"Ceph 内核工程视角"了

1️⃣ `client_die_on_failed_remount`

2️⃣ `client_dirsize_rbytes`（CephFS 专用）

3️⃣ `client_oc_size`

4️⃣ `client_oc_max_objects`

和 `client_oc_size` 的关系

5️⃣ `client_oc_target_dirty`（非常重要）

这是一个软阈值

6️⃣ `client_oc_max_dirty`

和 `target_dirty` 的区别

7️⃣ `client_oc_max_dirty_age`

六、这和你前面学的 `debug_asok = 16/0` 是怎么对齐的？