ceph16-18差异

1. 数据一致性维度

1.1 RBD：compare-and-write 语义与 C API 一致，修复跨条带边界不一致风险

是否存在该变化（是否 Ceph18 才有） ：存在，且属于 **Ceph18（v18.2.0 Reef）**新增/变更点。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
含义：
compare-and-write 是原子条件写（CAS-like）：只有当目标区域与 compare buffer 匹配时才写入。Reef 将 C++ API 的 compare/write 语义对齐到 C API ：比较与写入都严格按 len 生效，避免旧行为在跨 stripe unit 边界时出现隐蔽偏差。 (Ceph)
为什么要做这个变化 ：

旧行为在 compare buffer 大小与条带边界交错时可能产生"subtle breakage"，对上层（QEMU、日志、分布式锁、增量同步）是高风险隐患。 (Ceph)
对生产的作用：
1. 元数据/日志类工作负载原子更新更可靠；2) 降低边界条件触发的偶发一致性缺陷；3) 可观测性更好（更明确的 compare 成功/失败）。
如何使用/如何验证 ：
API 使用（按官方条目命名）：
- C++：Image::compare_and_write / Image::aio_compare_and_write
- C：对应 C API compare-and-write 族接口
  以上 API 语义变化（len 生效方式）详见：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
  验证建议：
- 在测试镜像上构造"跨 stripe unit 边界"的 compare-and-write（例如 compare 区域末端跨过 stripe unit），分别在升级前后对比：升级后应表现为严格按 len 比较/写入。
- 若你们有自研/三方使用 C++ compare-and-write 的组件（QEMU/自研块层），建议补一条回归用例：compare buffer > len 且跨 stripe unit。

1.2 RBD：支持多段读写 compare-and-writev（scatter/gather）

是否存在该变化（是否 Ceph18 才有） ：存在，且为 **Ceph18（v18.2.0 Reef）**新增。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
含义：

新增 rbd_aio_compare_and_writev：compare 缓冲区与 write 缓冲区都支持 scatter/gather，减少上层拼接/拷贝。 (Ceph)
为什么要做这个变化 ：

复杂应用普遍用多段内存结构；强制拼连续 buffer 会增加 CPU/带宽与尾延迟。
对生产的作用：
1. 吞吐更高、CPU 更省；2) 降低用户态拼包抖动；3) 高并发异步 I/O 更稳定。
如何使用/如何验证 ：
API 使用：
- C AIO：rbd_aio_compare_and_writev（与 rbd_aio_readv / rbd_aio_writev互补）
  证据链接：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
  验证建议：
- 在调用侧刻意使用多段 iovec（例如 4~16 段），对比升级前（需要拼接）与升级后（直接 iovec）CPU 与 P99 延迟。

1.3 RBD：fast-diff + whole_object==true 的 diff 计算问题修复

是否存在该变化（是否 Ceph18 才有） ：存在相关修复，但不是 Ceph18 才有 。

证据链接：https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/ (Ceph)

（官方明确：该类问题在 Quincy 提到，并说明也修到 16.2.8 等。） (Ceph)
含义：

fast-diff + whole object(inexact) 在少数情况下可能导致 diff/export 结果不正确，影响 rbd export 等链路。 (Ceph)
为什么要做这个变化 ：

diff/export/增量同步属于"数据正确性链路"，一旦 diff 错误，上层备份一致性会被破坏。
对生产的作用：
1. 备份/导出/增量同步正确性更可靠；2) 降低潜在数据完整性风险。
  备注：你原先写"Ceph16 没有、Ceph18 才有"在此条不成立（官方指出已在更早分支修复）。 (Ceph)
如何使用/如何验证 ：
使用路径：
- rbd diff / rbd export-diff / rbd export（以及上层 QEMU live sync/backup 调用 diff-iterate）
  验证建议：
- 选择启用了 fast-diff 的镜像，构造 whole_object(inexact) + fromsnapname==NULL 的 diff 场景，对比升级前后 diff 结果一致性；必要时对照 rbd export 的校验（hash/校验和）。

1.4 RBD：Windows VM 性能优化，修复 krbd 的 rxbounce 问题

是否存在该变化（是否 Ceph18 才有） ：存在，但不是 Ceph18 才有 （Quincy 已提）。

证据链接：https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/ (Ceph)

另：Pacific release notes 提到"识别 rxbounce map option"。

证据链接：https://docs.ceph.com/en/latest/releases/pacific (Ceph 文档)
含义：

官方定位为 Windows VM 在 krbd 下可能出现性能劣化，建议参考 rxbounce map 选项说明。 (Ceph)
为什么要做这个变化 ：

虚拟化 I/O 对尾延迟敏感，Windows I/O/驱动栈更容易放大内核块映射路径的抖动。
对生产的作用：
1. Windows VM I/O 更稳；2) 降低偶发性能劣化；3) 更利于混合 OS 虚拟化集群使用 krbd。
如何使用/如何验证 ：
使用：
- rbd map 支持通过 --options/ -o 传入 krbd-options。
  证据链接：https://docs.ceph.com/en/reef/man/8/rbd/ (Ceph 文档)
- Pacific notes 说明 rxbounce 为可识别的 map option。
  证据链接：https://docs.ceph.com/en/latest/releases/pacific (Ceph 文档)
  命令示例（示意）：
- rbd map <pool>/<image> -o rxbounce（具体以你们版本的 rbd --help/manpage 为准）
  验证建议：
- Windows VM + krbd 场景，对比开启/关闭该选项的 P99 延迟、抖动与吞吐（重点看随机写与小块 IO）。

1.5 版本化 bucket 管理加强：bucket check olh / unlinked + 修复 index stats 不一致

是否存在该变化（是否 Ceph18 才有） ：存在，且属于 **Ceph18（v18.2.1 Reef）**新增。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-1-reef-released/ (Ceph)
含义：
- bucket check olh：检查/清理版本化桶索引中多余的 olh（object logical head）与占位条目；
- bucket check unlinked：检查/清理"不可列举但占空间"的 unlinked objects；
- 同时修复 index stats 与旧 recalculation 工具链的缺陷。 (Ceph)
为什么要做这个变化 ：

历史 bug 会造成"索引长期污染/隐藏对象长期存在"，需要可操作的审计与修复工具闭环。 (Ceph)
对生产的作用：
1. 降低 listing 延迟与 lifecycle 失败概率；2) 提供可审计、可修复的一致性治理手段；3) 多站点/版本化桶长期运维价值高。 (Ceph)
如何使用/如何验证 ：
使用（官方在 release notes 给出命令名与 --fix 行为）：
- 检查：radosgw-admin bucket check olh / radosgw-admin bucket check unlinked
- 修复：加 --fix（官方说明会"safely removed"） (Ceph)
  验证建议：
- 对问题桶执行 check（不加 fix）记录输出；
- 维护窗口执行 --fix 后复查 listing 延迟、lifecycle 任务错误率、以及桶统计是否回归合理。

1.6 read balancer（离线工具）：通过调整 primary PG 映射提升读负载均衡

是否存在该变化（是否 Ceph18 才有） ：存在，且为 **Ceph18（v18.2.0 Reef）**新增。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
含义：

聚焦 primary PG 分布 ，通过更合理的 primary 分配为读热点削峰；目前以离线 osdmaptool 方式提供（可预览、可选择应用）。 (Ceph)
为什么要做这个变化 ：

primary 偏斜会让少数 OSD/网卡成为瓶颈，放大超时与尾延迟。
对生产的作用：
1. 读吞吐与尾延迟更稳定；2) 降低热点 OSD 连锁慢请求；3) 运维可先预览再应用，风险可控。 (Ceph)
如何使用/如何验证 ：
使用（推荐操作框架，不硬写参数以避免误导）：
1. 导出 osdmap（例如 ceph osd getmap -o osdmap.bin）；
2. 离线运行 osdmaptool 的 read balancer 相关子命令/参数，对指定 pool 生成 primary PG 映射优化预览；
3. 评审后再应用到集群。上述"离线预览 + 可选择应用"的机制在 release notes 已说明。 (Ceph)
  回滚/清理：
- Reef 文档提到新增 ceph osd rm-pg-upmap-primary-all 用于清理 pg-upmap-primary 映射。
  证据链接：https://docs.ceph.com/en/latest/releases/reef/ (Ceph 文档)
  验证建议：
- 应用前后对比：热点 OSD 的 op latency、client read 分布、以及 pool 级别读延迟 P95/P99。

2. 集群可靠性维度

2.1 OSD：recovery/backfill 高 CPU 占用问题修复

是否存在该变化（是否 Ceph18 才有） ：存在，但不是 Ceph18 才有（Quincy backport 已写明修复）。

证据链接：https://docs.ceph.com/en/latest/releases/quincy/ (Ceph 文档)
含义：

recovery/backfill 属于后台重建路径；CPU 异常会挤压前台 client I/O，导致抖动与不可预测延迟。 (Ceph 文档)
对生产的作用：
1. 故障恢复期间更稳；2) 前台 I/O 受影响更小；3) 资源利用更可控。 (Ceph 文档)
如何使用/如何验证 ：
使用：无需额外开关，属于 bugfix。
验证建议：
- 人为触发 backfill（例如小规模 OSD out/in 或添加 OSD），对比升级前后 OSD CPU、前台延迟与 slow requests。

2.2 ceph-volume：激活延迟修复（你标注为 17.2.5）

是否存在该变化（是否 Ceph18 才有） ：存在，但不是 Ceph18 才有；Quincy v17.2.5 明确提到修复 activate 变慢的 regression。

证据链接：https://docs.ceph.com/en/latest/releases/quincy/ (Ceph 文档)
含义：
ceph-volume lvm activate 异常变慢会拉长节点恢复窗口，影响维护/扩容/故障自愈速度。 (Ceph 文档)
对生产的作用：
1. 节点重启/OSD 重建更快；2) 维护窗口更短；3) 自动化编排成功率更高。
如何使用/如何验证 ：
使用：
- 常见运维命令：ceph-volume lvm activate --all（或按 OSD id 激活）。
  验证建议：
- 统计升级前后 OSD 激活耗时（systemd 启动耗时、cephadm 编排耗时），确认"异常变慢"现象消失。 (Ceph 文档)

2.3 libcephsqlite 崩溃修复（提升 MGR 稳定性）

是否存在该变化（是否 Ceph18 才有） ：存在，但不是 Ceph18 才有（Quincy backport 版本中有 mgr 崩溃修复条目）。

证据链接（Quincy 17.2.3 release blog）：https://ceph.io/en/news/blog/2022/v17-2-3-quincy-released/ (Ceph)
含义：

mgr 负责 dashboard/telemetry/编排与健康模块；反复崩溃导致管理平面不稳定并影响自动化动作。 (Ceph)
对生产的作用：
1. 管理平面更稳定；2) dashboard/监控/自愈模块可用性更好；3) 降低升级后 mgr 不可用风险。
如何使用/如何验证 ：
使用：无需额外开关，属于 bugfix。
验证建议：
- 升级后观察 mgr 是否还出现 crash loop；
- 用 ceph mgr dump、dashboard 可用性、以及告警稳定性做回归。

2.4 MDS 升级是否"无需停止 standby MDS"（你原始表述的核验更新）

这里建议把你原条目改成"升级编排要求与不同版本行为差异"，因为官方材料同时存在两类信息：

Reef CephFS 升级文档（操作要求） ：升级流程明确要求对每个 FS disable & stop standby-replay ：

证据链接：https://docs.ceph.com/en/reef/cephfs/upgrading/ (Ceph 文档)

文档同时说明：在 Pacific ，执行 ceph fs set <fs_name> allow_standby_replay false 后，standby-replay 会自动停止；更老版本需要手动 stop。 (Ceph 文档)
Quincy release notes（能力表述） ：release notes 中出现"升级 MDS 不再需要停止全部 standby daemon"的描述（但与上面的"standby-replay 处理"并不完全等价）。

证据链接：https://docs.ceph.com/en/latest/releases/quincy (Ceph 文档)
建议在报告中更可靠的写法（合并版）：
1. 升级仍需要处理 standby-replay（以降低升级期间状态复杂度）；
2. 部分版本/场景下，升级不一定要求"停止所有 standby"（以官方 release notes 为准），但应以你们集群实际角色（standby vs standby-replay）做区分。 (Ceph 文档)
如何使用/如何验证 ：

按 Reef 文档执行：
- ceph fs set <fs_name> allow_standby_replay false（Pacific 会自动停）
- ceph fs dump 找到 standby-replay 守护进程，必要时 ceph mds fail mds.<X> 逐个下线
  证据链接：https://docs.ceph.com/en/reef/cephfs/upgrading/ (Ceph 文档)

2.5 RocksDB 与调度器优化：RocksDB 升级至 7.9.2（含列族级调优能力）

是否存在该变化（是否 Ceph18 才有） ：存在，且为 **Ceph18（Reef）**强调项。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
含义：

RocksDB 升级至 7.9.2，并首次支持按 column family 粒度调参，使不同类型数据可采用更合适的策略。 (Ceph)
对生产的作用：
1. 迭代开销降低、性能更稳；2) 提供更可控的调参空间；3) 大集群 RocksDB 相关抖动风险下降。 (Ceph)
如何使用/如何验证 ：
使用：
- 该项更多体现为默认参数与内部能力增强；如需列族级调优，建议严格按 Reef/官方参数说明在测试环境验证后再上线。 (Ceph)
  验证建议：
- 升级后对比 RGW/OSD 元数据类 workload 的 compaction、写放大、以及 P99 延迟。

2.6 mClock Scheduler 优化：提升 client 与 recovery I/O 调度能力

是否存在该变化（是否 Ceph18 才有） ：部分成立。mClock 在 Quincy 已为默认调度器，但 Reef 做了显著可用性/设计改进（profile 默认、QoS 表达、成本模型、degraded 优先等）。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
含义：

mClock 是 QoS 调度框架，让前台与后台资源权衡更可配置、更符合直觉。 (Ceph)
对生产的作用：
1. 故障/扩容/回填期间业务更稳；2) 恢复吞吐更可预测；3) 更易运维化。
如何使用/如何验证 ：
使用：
- 关键在选择 profile：balanced（默认）、high_client_ops、high_recovery_ops。 (Ceph)
- 配置参考（官方 config ref 链接在 release notes 中给出）：https://docs.ceph.com/en/reef/rados/configuration/mclock-config-ref/ (Ceph)
  验证建议：
- 在 backfill/recovery 期间对比 profile 切换前后：client 延迟、recovery 速度、以及 slow ops。

3. 集群治愈性维度

3.1 BG/PG 治愈性增强：degraded 优先于 misplaced（mClock 方向）

是否存在该变化（是否 Ceph18 才有） ：不是 Ceph18 独有，但 Reef 明确强调并落地。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
含义：

degraded（副本不足，数据安全风险）优先于 misplaced（副本满足阈值但位置不理想）。 (Ceph)
对生产的作用：
1. 故障期间更快回到安全副本数；2) 降低二次故障导致的数据风险；3) 某些 profile 下 backfill 可能更慢（官方提示过）。 (Ceph)
如何使用/如何验证 ：
使用：主要体现在 mClock profile 与恢复策略的默认行为。
验证建议：
- 制造 degraded + misplaced 并存的恢复场景，观察恢复队列优先级与修复顺序是否符合预期。

3.2 恢复智能调度增强：backfill/recovery 优化

是否存在该变化（是否 Ceph18 才有） ：部分成立，Ceph17/18 均在持续优化。

（Ceph18 从 mClock 设计与 QoS 表达做系统改进。）

证据链接：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
含义与生产作用 ：

更合理的限速/队列/成本模型，减少恢复对前台冲击并提升恢复效率。 (Ceph)
如何使用/如何验证 ：

参考 mClock config ref： https://docs.ceph.com/en/reef/rados/configuration/mclock-config-ref/ (Ceph)

通过 profile 与 QoS 参数做 A/B 回归：恢复窗口、业务抖动、P99 延迟。

3.3 恢复工具增强：`trim-pg-log-dups`（OSD 无法启动时的离线修复）

是否存在该变化（是否 Ceph18 才有） ：存在，但不是 Ceph18 才有（Quincy backport 已引入离线 op；Reef 也再次强调）。

证据链接（Quincy notes，含离线 op 描述）：https://docs.ceph.com/en/latest/releases/quincy/ (Ceph 文档)

证据链接（Reef 18.2.0 notes 也提及）：https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
含义：

PGLog dups 异常膨胀可能导致 OSD 启动失败；提供离线修复闭环。 (Ceph 文档)
对生产的作用：
1. 提升极端故障可恢复性；2) 减少人工重建/数据丢失风险；3) 大规模集群尤为关键。
如何使用/如何验证 ：
使用：
- ceph-objectstore-tool 新增 trim-pg-log-dups op，用于 OSD 无法启动时的离线修复（OSD log 可能出现 "THE DUPS BUG" 提示）。 (Ceph 文档)
  验证建议：
- 演练：在测试环境构造 PG split + trim jam（或回放历史问题），确认离线工具可让 OSD 重新启动并恢复 peering。

3.4 RGW：bucket resync（加密 multipart 对象不一致修复）

是否存在该变化（是否 Ceph18 才有） ：存在，且为 **Ceph18（v18.2.1 Reef）**新增。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-1-reef-released/ (Ceph)
含义：

multisite + SSE + multipart 组合下，历史版本可能出现复制副本解密后损坏；新增
radosgw-admin bucket resync encrypted multipart 用于识别原始 multipart 并触发重新复制（通过 LastModified +1ns 促发）。 (Ceph)
对生产的作用：
1. 多站点对象完整性更可靠；2) 提供升级后治理动作（官方建议对所有 bucket 执行）。 (Ceph)
如何使用/如何验证 ：
使用：
- 在所有 zone 升级完成后，对每个 bucket 执行：radosgw-admin bucket resync encrypted multipart（官方建议覆盖所有 bucket/zone）。 (Ceph)
  验证建议：
- 对历史 SSE multipart 对象做抽样校验（下载解密校验、ETag/校验和或应用层校验），确认副本一致。

4. 汇总：哪些是"Ceph18 才有"，哪些不是

4.1 明确属于 "Ceph16 没有、Ceph18 才有"（按你清单中可被官方材料支撑的部分）

RBD compare-and-write 语义对齐 C API、修复跨条带边界隐患（v18.2.0）
https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
RBD rbd_aio_compare_and_writev（v18.2.0）
https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
RGW versioned bucket 治理工具：bucket check olh/unlinked + 修复 index stats 不一致（v18.2.1）
https://ceph.io/en/news/blog/2023/v18-2-1-reef-released/ (Ceph)
read balancer（离线 osdmaptool，v18.2.0）
https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
RocksDB 升级至 7.9.2，且首次可按列族调参（Reef）
https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ (Ceph)
RGW bucket resync encrypted multipart（v18.2.1）
https://ceph.io/en/news/blog/2023/v18-2-1-reef-released/ (Ceph)

4.2 不属于 "Ceph18 才有"（Ceph16/17 已存在或已修复）

fast-diff + whole object(inexact) diff 计算问题：Quincy 提到并说明也修到 16.2.8 等
https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/ (Ceph)
Windows VM + krbd 性能问题：Quincy 提到，并指向 rxbounce 选项；Pacific notes 也提到识别该选项
https://ceph.io/en/news/blog/2022/v17-2-0-quincy-released/ (Ceph)
https://docs.ceph.com/en/latest/releases/pacific (Ceph 文档)
recovery/backfill 高 CPU：Quincy backport notes 写明已修复
https://docs.ceph.com/en/latest/releases/quincy/ (Ceph 文档)
ceph-volume activate 变慢 regression：Quincy v17.2.5 notes 写明修复
https://docs.ceph.com/en/latest/releases/quincy/ (Ceph 文档)
libcephsqlite 导致 mgr 崩溃：Quincy v17.2.3 release blog 有修复条目
https://ceph.io/en/news/blog/2022/v17-2-3-quincy-released/ (Ceph)
trim-pg-log-dups：Quincy notes 已写明并提供离线 op
https://docs.ceph.com/en/latest/releases/quincy/ (Ceph 文档)

5. 你原始清单中"暂无法按字面验证"的点（给出可替代的官方可证据项）

你原文提到的 "MDS 日志回放失败处理增强"，在你上面那段"Reef 发行说明检索不到"这一判断，建议改写为如下两条"更可审计、可引用"的表述（二选一或都写）：

Quincy release notes 中明确出现与 CephFS journal replay failure 相关的行为描述 （例如将 rank 标记为 damaged 等）。

证据链接：https://docs.ceph.com/en/latest/releases/quincy (Ceph 文档)
若你希望把它放在 Ceph18 里，也可以写成 "CephFS/运维工具链与恢复流程持续增强（含对异常会话/元数据膨胀的处置）"，例如 v18.2.1 提到 MDS 会驱逐不推进 request tids 的客户端以避免会话元数据膨胀导致 MDS 只读。

证据链接：https://ceph.io/en/news/blog/2023/v18-2-1-reef-released/ (Ceph)

附：你这份稿子落地到"评审模板"时，建议统一增加的验证项（通用）

为避免每条都写得过碎，你们内部模板可额外加一段"通用验证"：

版本确认 ：ceph versions、ceph -v、容器镜像 tag
健康与恢复面 ：ceph -s、ceph health detail、ceph osd perf、ceph tell osd.* dump_ops_in_flight
RBD 链路 ：rbd info、rbd feature enable/disable、rbd export/export-diff/diff
RGW 链路 ：执行 radosgw-admin check/resync 后的抽样校验（对象可读性、解密一致性、list/lifecycle 成功率）

如果你希望我下一步把这份"合并稿"进一步整理成你们内部常用的 《版本对比评审模板》（背景/范围/变更清单/升级建议/风险与回滚/验证用例），我也可以直接按模板输出一个可直接贴到评审系统的版本。