nearfull告警本身不阻断写入，真正停写的是full状态、ceph osd pause、PG backfill_toofull或peering失败；需用ceph health detail、ceph osd dump | grep paused、rados df -p等命令精准定位根因，而非盲目调阈值或权重。
直接结论：nearfull 告警本身不会阻断写入，但伴随的 full 状态、OSD reweight 失败、PG backfill_toofull 或 osd pause 才会真正停写——得先分清是“告警”还是“实际写入失败”。
确认到底是 nearfull 还是 full 导致写入失败
很多运维一看到 nearfull osd(s) 就急着调权重，结果发现写入还是卡住。这是因为 nearfull 只触发 HEALTH_WARN，而真正阻断写入的是 full（HEALTH_ERR）或人工执行了 ceph osd pause。
- 运行
ceph health detail，重点看有没有full osd(s)或pool(s) full字样； - 检查是否有
osd pause：执行ceph osd dump | grep paused，输出非空即表示写入已被手动暂停； - 查 pool 容量：用
radosdf -p {pool_name}看实际使用率，注意它和ceph osd df的单位可能不一致（前者按对象计，后者按磁盘块）； - 别只信告警文本——
ceph -s输出里的health:行才是权威状态。
为什么调高 mon-osd-nearfull-ratio 常常没用
临时抬高阈值（比如从 0.85 改到 0.96）能压住告警，但解决不了根本问题：数据分布不均。如果某几个 OSD 实际使用率已达 92%，再把 nearfull 阈值提到 0.97，只会让问题延后爆发，且可能掩盖 PG backfill_toofull 卡死。
- 调整命令必须同时发给 mon 和 osd：仅改 mon 配置，OSD 不会自动 reload；
- 执行
ceph tell mon.* injectargs "--mon-osd-nearfull-ratio 0.96"后，立刻用ceph --admin-daemon /run/ceph/ceph-mon.IP.asok config show | grep nearfull验证是否生效； - PG 层也有独立阈值：
ceph pg set_nearfull_ratio 0.96，漏掉这步，PG 状态仍可能报 stuck； - 更危险的是：盲目调高 full_ratio 到 0.97+，一旦某个 OSD 真达到 98%，CRUSH 无法再迁移数据，
backfill_toofull会雪球式增长。
数据不均衡时，ceph osd reweight-by-utilization 为什么有时失效
这个命令本质是按当前利用率反推权重，但它依赖 CRUSH map 的拓扑结构和 PG 分布逻辑。当 OSD 已 nearfull，新 PG 往它上面映射的概率极低，reweight 后数据迁移速度会非常慢，甚至卡在 backfill_toofull。
- 先执行
ceph osd set noout和ceph osd set nodeep-scrub，避免迁移过程中触发额外 IO 压力； - 参数不是随便填：若
ceph osd df | sort -nk7 | tail -5显示 top5 OSD 利用率方差（var）为 1.22，就该用ceph osd reweight-by-utilization 122，而不是拍脑袋写 110； - 对已卡住的 PG（如
2.689），用ceph pg map 2.689查出它的 up_set（比如 osd.153 在其中），再单独降权：ceph osd crush reweight osd.153 0.75； - 权重不能低于 0.1，否则 CRUSH 认为该 OSD 不可用，可能引发 PG unfound。
真正卡写入时，最该盯住的三个地方
写入阻塞往往不是单一原因，而是多个环节叠加。优先检查这三项，比反复调 ratio 更有效：
-
ceph pg dump_stuck inactive：如果有 PG 卡在 inactive，说明 peering 失败，所有写请求会 hang 在该 PG 上； -
ceph osd perf：看commit_latency_ms和apply_latency_ms是否持续 >500ms，超高延迟的 OSD 很可能是慢盘或 IO 饱和； -
ceph daemon osd.x dump_ops_in_flight：挑一个疑似卡住的 OSD，看当前操作里有没有大量op_type: write停在waiting_for_map或waiting_for_backfill状态。
复杂点在于：nearfull 是表象，背后可能是某块 SSD 老化导致写放大、也可能是网络抖动让 backfill 持续失败、还可能是 CRUSH rule 设置了错误的 failure domain 导致数据只能往少数 OSD 上挤——得一层层剥开，不能只盯着告警文本改数字。
