2022.8.24 更新：已找到原因
环境信息
一共三套 Ceph 环境进行对比，配置如下：
| 配置\版本 | 12.2.12 | 12.2.13 | 14.2.16 |
|---|---|---|---|
| 节点数量 | 10 | 10 | 10 |
| HDD 数量 | 360 | 360 | 360 |
| HDD 规格 | 10TB | 10TB | 10TB |
| 物理容量 | 3.2PiB | 3.2PiB | 3.2PiB |
| 使用场景 | cephfs | cephfs | cephfs |
| 文件系统 | bluestore | bluestore | bluestore |
| cephfs_data PG 数 | 8192 | 8192 | 8192 |
| cephfs_Metadata PG 数 | 128 | 512 | 512 |
| EC k+m 值 | 3+2 | 3+2 | 3+2 |
问题描述
从配置中可以 看出，三个集群磁盘规格一致（均为 10TB SATA 盘，可用容量为 9.1TiB），磁盘数量一致，裸容量一致，使用场景一致，文件系统一致，EC 配置一致。除 Metadata 的 PG 数量有差异外，其他配置均一致。
其中：
12.2.12 版：
12.2.13 版：
14.2.16 版：
- 使用时间：2020.12 ~ 2021.2。
- 使用场景：用于迁移
12.2.12集群的数据，使用 rsync 同步，基本无新增数据。
当前使用量对比：
| 使用量\版本 | 12.2.12 | 12.2.13 | 14.2.16 |
|---|---|---|---|
| OSD 最小使用率 | 81.73% | 64.49% | 78.14% |
| OSD 最大使用率 | 88.46% | 85.25% | 84.74% |
| balancer eval（lower is better） | 0.001501 | 0.008677 | 0.012148 |
| 总文件数 | 23962401 | 30633954 | 23962496 |
| 总目录数 | 1769645 | 1748059 | 1769731 |
| 逻辑占用空间(单位：bytes) | 1703433403704970 | 1310466730271210 | 1703436500803050 |
| 逻辑空间使用率 | 90.23% | 86.15% | 88.82% |
| 物理容量(单位：bytes) | 3600297775595520 | 3600297775595520 | 3600297775595520 |
| 物理占用空间(单位：bytes) | 3152820451147770 | 2947490151464960 | 2938495125159930 |
| 物理空间使用率 | 87.57% | 81.87% | 81.62% |
| 基于逻辑占用空间计算出的应该占用物理空间 | 2839055672841620 | 2184111217118680 | 2839060834671750 |
| 应该占用物理空间与实际占用物理空间的比值 | 90.05% | 74.10% | 96.62% |
| 应该占用物理空间使用率 | 78.86% | 60.66% | 78.86% |
| 应该使用率与实际物理使用率差值 | 8.71% | 21.20% | 2.76% |
从上面表格中可以得出以下结论：
- 从 balacer 得分看，
12.2.12优于12.2.13优于14.2.16； -
12.2.12的数据使用 rsync 全部同步到14.2.16，在总文件数和逻辑占用空间几乎一样时，两个集群的物理使用率相差 6%； - 在集群整体使用率均超过 80% 后，
12.2.12的物理损耗空间达到 8.71%，14.2.16的物理损耗空间达到 2.76%，而12.2.13的物理损耗空间甚至达到恐怖的 21.20%；
可能的原因推测
- Ceph Luminous 的 bluestore 有 bug ，但已在后续版本中修复；
- Ceph Luminous 的 bluestore + EC 才能触发的 bug，但已在后续版本中修复；
- 由于
14.2.16的数量为一次上传完成，可能是由于 12 版本在正常使用过程中有删除修改等操作，产生的脏数据未能成功回收所致，14 版本有可能也未修复此 bug；
根因已找到
ceph Luminous 的 bug，bluefs 的 log compact 功能不生效。
解决办法
任选其一：
