开始
喜欢ceph的话欢迎关注奋斗的cepher微信公众号阅读更多好文！
关于osd的问题总是各种各样，奇奇怪怪，有bug相关的，也有环境相关的，或者是配置相关的，对于osd各种问题的处理，重点在思路，思路对了，问题就好解决了。
本篇是一个集群有ssd的osd发生down，这本不是什么值得关注的事，osd的down太常见了，多为坏盘引发，但奇怪的是它down并不是配置、环境、硬件引发，十分奇怪。
因此松鼠哥在本篇尽可能从思路角度分析，希望对大家有帮助。
排查
首先osd的down应该是看它的日志，报错比较明显：
-465> 2024-09-19 22:33:50.439 7f4877aee700 2 rocksdb: [/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/gigantic/release/13.2.10/rpm/el7/BUILD/ceph-13.2.10/src/rocksdb/db/db_impl_compaction_flush.cc:1517] Waiting after background compaction error: Corruption: block checksum mismatch: expected 3752980306, got 1569966253 in db/175779.sst offset 2206199009 size 4080, Accumulated background error counts: 1
-465> 2024-09-19 22:33:50.439 7f486f2dd700 -1 rocksdb: submit_common error: Corruption: block checksum mismatch: expected 3752980306, got 1569966253 in db/175779.sst offset 2206199009 size 4080½{OV code = 2 Rocksdb transaction:
Put( Prefix = S key = 'nid_max' Value size = 8)
Put( Prefix = S key = 'blobid_max' Value size = 8)
SingleDelete(Prefix = L Key = 0x0000000000000001)
SingleDelete(Prefix = L Key = 0x0000000000000002)
SingleDelete(Prefix = L Key = 0x0000000000000003)
是rocksdb的sst文件它的checksum有问题，通常，这种checksum问题大概率就是对应的地方有坏道、逻辑错误等，由于osd使用了blustore，我们能够对rocksdb进行的操作十分有限，而且sst文件损坏并不容易修复，因此最好采取的办法就是重建该osd，简单粗暴但有效。
于是，松鼠哥先对该osd进行了删除，然后进行重建，重建完成后，osd拉起来，数据均衡一会后，发现仍然报checksum的错误：
-10001> 2024-09-20 00:53:41.753 7fd7d43bf700 -1 rocksdb: submit_common error: Corruption: block checksum mismatch: expected 2253949442, got 530591794 in db/000178.sst offset 2147479191 size 40720033-pop^N\+UV code = 2 Rocksdb transaction:
-10001> 2024-09-20 00:53:41.754 7fd7d43bf700 -1 /home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/gigantic/release/13.2.10/rpm/el7/BUILD/ceph-13.2.10/src/os/bluestore/BlueStore.cc: In function 'void BlueStore::_kv_sync_thread()' thread 7fd7d43bf700 time 2024-09-20 00:53:41.754655
报错信息与此前相比有所不同，但都是checksum的问题，关键是，多次重建发现，osd居然都报同样的错误，更奇怪的是，多次重建发现它报错的文件名字是一样的，重建了个寂寞？？
按道理讲，重建osd后，osd上是完全没有数据的，这些数据都需要从别的osd通过backfill得到，那么就不太可能产生问题才对，有没有可能是别的osd本身数据有问题，backfill给这个osd之后，导致了这个osd的down？
可是，别的osd都不挂，就只有这个osd挂，而且，如果数据本身有问题，别的osd应该也早就发现了，不会现在才触发。
OK，那么如果数据是没有问题的，那么是盘有问题吗？os层面查了一圈，没有任何报错。
通过硬件专家的分析，盘，是ok的，没有异常。
那么就要开始松鼠哥的思路了(有猜测的成分)，有没有可能盘是某个地方逻辑错误了，重建并不能处理这个错误，从而导致了持续的相同的问题？
在原盘上重建osd，首先是删除，松鼠哥采取的方法是通过lvremove、vgremove、pvremove的方式对盘进行处理，删掉lvm后重新建立lvm，但是，这里有个细节，重新建立的lvm与原来的lvm名字完全相同(这是因为创建osd要按照一定的规则命名，便于管理)，而删除lvm实际上只是在盘上将lvm的元数据信息清除，其他数据存放的地方是没有涉及清理的(这也给lvm的恢复提供可能性)，也就是数据部分的存储空间实际上没有被清理，如果那些地方有数据或者有错误，自然也不会被清理。
为了验证猜想，松鼠哥使用dd对整块ssd盘进行全盘置0，强行将可能的逻辑错误清除，首先是检查盘的确切大小：
[root@test-node-1 ceph]# parted /dev/sdh unit MiB print free
Error: /dev/sdh: unrecognised disk label
Model: ATA SAMSUNG MM7MM960 (scsi)
Disk /dev/sdh: 915715MiB
显然它是915715MiB的，以4MiB为单位，接下来用dd对盘进行低级格式化，也就是置0：
[root@test-node-1 ceph]# dd if=/dev/zero of=/dev/sdh bs=4194304 count=228928 oflag=direct
全盘置0所有的块都会跑到，所以要花点时间，不过是ssd的话速度很快。
完成后，对该盘重建osd，使用之前的lvm名字也能成功，跑观察了一段时间，数据恢复完成，没有见到报错了，说明低格有效。
[root@test-node-1 ceph]# ps -ef|grep ceph-osd|grep 2263
ceph 3888671 1 10 Sep23 ? 01:51:59 /usr/bin/ceph-osd -f --cluster ceph --id 2263 --setuser ceph --setgroup ceph
总结
不敢说是不是dd全盘置0起的作用，但是确实这个osd通过这方法修好了。 如果有遇到类似情况且有其他思路的老铁，欢迎留言讨论~
喜欢ceph的话欢迎关注奋斗的cepher微信公众号阅读更多好文！