其实我对Ceph一知半解，照着quickstart教程安装上去。但是教程里有个坑爹的不良示范，它在/tmp下创建了osd存储目录。难道不知道系统重启后，/tmp内容都没有了么？结果我的存储节点上，创建了很多无用的osd配置。在写文件时，任何IO都不成功，ceph -s显示：
health HEALTH_WARN 192 pgs stale; 192 pgs stuck stale; 1/4 in osds are down
192个pg全部是stale。正常状态是active+clean。
执行ceph osd tree看到，只有如下2个osd进程正常：
10 0.07999 osd.10 up 1
11 0.07999 osd.11 up 1
其他0-9号进程都是down状态。好吧，哥逐个运行：
ceph osd rm 0 ... ceph osd rm 9
把这些osd都删除了。ceph health一看还是那个鬼样，于是一番google，发现pg可以重建。好在是测试环境，悠悠然重建之：
ceph health detail|awk '{print $2}' > pg.list
cat pg.list |while read LINE;do ceph pg force_create_pg $LINE;done
这个过程比较久。建完再运行ceph health，发现stale pg没有了，但变成了如下：
health HEALTH_WARN 135 pgs degraded; 135 pgs stuck unclean
192个pg里，有135个是degraded状态，同样写IO不成功。郁闷无比，再次祭起google，没有得到任何有用信息，只看到邮件列表存档上有这么一句：
Are you still seeing this problem? It looks like you have a bad crushmap.
哥充分发挥久已不用的聪明才智，转动脑经快速思考，crushmap是个神马玩意？
好在ceph -h输出信息量很大，grep一番后，键指如飞，敲入如下命令：
ceph osd getcrushmap -o /tmp/crushmap crushtool -d /tmp/crushmap
输出里包含：
item osd.0 weight 0.080
…
item osd.9 weight 0.080
item osd.10 weight 0.080
item osd.11 weight 0.080
osd.0到osd.9不是没用的么？果断删除之。
ceph osd crush rm osd.0 ... ceph osd crush rm osd.9
检查结果：
# ceph health
HEALTH_OK
大功告成。测试写操作也成功。
当然这纯粹是瞎折腾。但ceph自身的健壮性和可维护性，从我先后测试两次的结果来看，也是需要谨慎考量的。