配置组无法清空
有些情况下Ceph的配置组无法清空：
1. 只有一个OSD：如果你不是从quick start开始，只有一个OSD的话，你很可能会遇到问题。OSD会向监控上报其他的OSD，当需要拷贝数据的时候也需要和其他的OSD交互.如果你只有一个OSD，第二个OSD就不能检测到它的心跳数据。而且，如果你删除了一个OSD，只剩下一个OSD的时候，你也会遇到问题。第二个和第三个OSD会从另外的OSD那里得到配置组的数据，如果那个OSD缺失，这个过程就无法完成。因此，配置组一直保持在“stale”状态。
2. Pool Size = 1: 如果一个对象只有一个拷贝，其他的OSD无法告知该OSD它拥有哪些配置组。对于每个存在的OSD对应的配置组(参见ceph的pg dump)，你可以强制OSD检查它运行所需要的配置组。
ceph pg force_create_pg <pgid>
3. 3. CRUSH规则：另外一个配置组无法清空的情况是你的CRUSH 映射出现了错误。
一般来说，你应该在集群中运行多个OSD，pool size也应该大于1
配置组不响应
在某个步骤执行失败的时候通常配置组会进入"degraged"或者"peering"状态。通常，这些状态表明，程序正在从错误中恢复。但是，当一个配置组一直保持在这种状态，也许预示着一个更大的问题。因此，监控系统会在配置组卡在某个状态的时候发出警告。尤其需要检查这些状态:
   inactive - 配置组已经长时间处于非激活状态(比如，它一直无法处理读写请求)
   unclean - 配置组长时间未被清理(比如，它没有完全从上一个错误中恢复)
   stale - 配置组的状态没有被OSD更新过，意味着所有存储在该配置组的节点都down掉了
你可以用下面的方法列出不响应的配置组:
ceph pg dump_stuck stale
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean
对于处在stale状态的配置组，通常让对应的OSD运行起来即可。对于处在inactive的配置组，通常是peer问题(参见配置组不可用-Peering Failure)。 对于处在unclena状态的配置组，通常是由于恢复过程被阻止，导致无法完成，比如对象为找到(参见对象缺失问题)
配置组不可用 - 同等操作失败
在特定情况下，ceph-OSD同等进程会出现问题，导致PG无法激活。比如ceph的检测系统会报告：
ceph health detail
HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down
...
pg 0.5 is down+peering
pg 1.4 is down+peering
...
osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
我们查询集群以确定PG不可用的准确原因是:
ceph pg 0.5 query
{ "state": "down+peering",
 ...
 "recovery_state": [
      { "name": "Started\/Primary\/Peering\/GetInfo",
        "enter_time": "2012-03-06 14:40:16.169679",
        "requested_info_from": []},
      { "name": "Started\/Primary\/Peering",
        "enter_time": "2012-03-06 14:40:16.169659",
        "probing_osds": [
              0,
              1],
        "blocked": "peering is blocked due to down osds",
        "down_osds_we_would_probe": [
              1],
        "peering_blocked_by": [
              { "osd": 1,
                "current_lost_at": 0,
                "comment": "starting or marking this osd lost may let us proceed"}]},
      { "name": "Started",
        "enter_time": "2012-03-06 14:40:16.169513"}
  ]
}
恢复状态告诉我们peer被阻塞，因为ceph-OSD进程未运行，尤其是OSD.1 。这种情况下，我们可以启动指定的OSD，问题就会得到解决。
另外，如果OSD.1出现比较严重的错误(比如磁盘错误)，我们可以通知集群OSD.1缺失，让其尽量从其它地方获取。
重要：当集群不能保证数据的其它拷贝持久和最新的，这种方法会带来较大的风险。
引导ceph继续运行:
ceph osd lost 1
会启动恢复。
对象缺失
当一些错误同时出现时，会出现对象缺失:
ceph health detail
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
pg 2.4 is active+degraded, 78 unfound
这意味着存储集群知道一些对象(或者对象的拷贝)存在，但是没有发现它们的拷贝。下面是当PG的数据在ceph-OSD1和ceph-OSD2时的例子:
   1. OSD1不可用
   2. 只有OSD2处理写请求
   3. OSD1启动
   4. OSD1和OSD2重新通信，OSD1上缺失的对象进入恢复队列
   5. 在新对象完成拷贝前，OSD2 down掉
现在OSD1知道这些对象存在，但是找不到其拷贝.这种情况下，对那些对象的请求会被阻塞，集群会认为down掉的节点会很快恢复;这时候会返回一个IO错误给用户。
首先，你能用下面的方法判断哪些对象找不到:
ceph pg 2.4 list_missing [starting offset, in json]
{ "offset": { "oid": "",
    "key": "",
    "snapid": 0,
    "hash": 0,
    "max": 0},
"num_missing": 0,
"num_unfound": 0,
"objects": [
   { "oid": "object 1",
     "key": "",
     "hash": 0,
     "max": 0 },
   ...
],
"more": 0}
如果单次查询的列表过长，列表上会出现more，你可以继续查看剩下的列表.(最终命令行工具会隐藏它，但是暂时还未隐藏)
第二，你可以确定哪些OSD已经被探测或者包含数据:
ceph pg 2.4 query
"recovery_state": [
    { "name": "Started\/Primary\/Active",
      "enter_time": "2012-03-06 15:15:46.713212",
      "might_have_unfound": [
            { "osd": 1,
              "status": "osd is down"}]},
在这种情况下，比如，集群知道OSD.1也许有数据，但是OSD.1 down掉了了。所有可能的状态包括:
* already probed
* querying
* osd is down
* not queried (yet)
有时，集群需要一些时间来查询可能的位置。
对象也可能存在未列出的位置上。比如，如果一个ceph-OSDS被停止，而且被移出了集群，集群恢复之后，再次出现错误的时候就会遇到对象找不到的情况，被移出的ceph-OSD未被考虑进来。(这种情况是我们不愿意看到的)
如果所有可能的位置都已经被查询，但是对象仍然找不到，你也许不得不放弃那些对象了。这种情况也会报出一些错误，让集群知道已经执行的写操作要在数据恢复之前进行。将"unfound"对象标记为"lost":
ceph pg 2.5 mark_unfound_lost revert
最后,我们需要明确集群是如何处理丢失的对象的。当前支持的选项是“revert”，将对象恢复到之前的版本或者(当有副本时)忽略它。使用这个功能的时候要小心，因为它也许会让使用它的程序产生错误。
配置组无归属
即使所有的OSD都有某个配置组的拷贝也可能会失败。如果是这种情况，对象存储的子集不可用，监控系统会收不到那个配置组的状态更新。为了检测到这种情况，监测系统会将主OSD失败的配置组标记为stale。比如:
ceph health
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
你可以用下面的方式找出那些配置组是stale状态和上一次存储它们的是哪些OSD
ceph health detail
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
...
pg 2.5 is stuck stale+active+remapped, last acting [2,0]
...
osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080
osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539
osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
如果我们想让配置组恢复到在线状态，比如，这告诉我们它之前是OSD.0和osd.2管理的。重启ceph-osd进程会让集群恢复这个配置组(其它也一样)
OSD接收仅少量的数据
如果你的集群有许多节点，只有部分能收到数据，检查你的资源池的配置组数量，因为配置组和OSD有映射关系，一小部分的配置组不会覆盖到你的整个集群。尝试创建一个新的资源池，保证配置组的数量是OSD数量的倍数。参加配置组章节。默认的配置组数量并没有效，你可以修改它。
无法写入数据
如果你的集群在运行状态中，但是一些OSD down掉了，你无法写入数据，检查一下，确保你的OSD是够用的。如果你OSD数量过少，ceph不会允许你写入数据，因为ceph无法保证能够拷贝你的数据。参见Pool，PG和CRUSH配置中的osd资源值的最小值。
pg 不一致问题
HEALTH_ERR 1 pgs inconsistent; 1 scrub errors 报不一致问题。先查看不一致pg id：  ceph health detail
修复pg : ceph pg repair pgid