2016-06-22 11:40:17.639591 2b067aa0e700 10 adding .rgw+.bucket.meta.im-core-prd-aa-s100-30:mzone.1461106.2611 to cache LRU end
2016-06-22 11:40:17.639593 2b067aa0e700 10 updating xattr: name=user.rgw.acl bl.length()=163
2016-06-22 11:40:17.639596 2b067aa0e700 20 get_obj_state: s->obj_tag was set empty
2016-06-22 11:40:17.639598 2b067aa0e700 20 Read xattr: user.rgw.acl
2016-06-22 11:40:17.639599 2b067aa0e700 20 Read xattr: user.rgw.idtag
2016-06-22 11:40:17.639600 2b067aa0e700 20 Read xattr: user.rgw.manifest
2016-06-22 11:40:17.639604 2b067aa0e700 10 cache get: name=.rgw+.bucket.meta.im-core-prd-aa-s100-30:mzone.1461106.2611 :type miss (requested=17, cached=22)
2016-06-22 11:40:17.639607 2b067aa0e700 20 get_obj_state: rctx=0x2b067aa0d0e0 obj=.rgw:.bucket.meta.im-core-prd-aa-s100-30:mzone.1461106.2611 state=0x2b06681eda90 s->prefetch_data=0
2016-06-22 11:40:17.639621 2b067aa0e700 20 rados->read ofs=0 len=524288
2016-06-22 11:40:17.640115 2b067aa0e700 20 rados->read r=0 bl.length=226
2016-06-22 11:40:17.640128 2b067aa0e700 10 cache put: name=.rgw+.bucket.meta.im-core-prd-aa-s100-30:mzone.1461106.2611
2016-06-22 11:40:17.640130 2b067aa0e700 10 moving .rgw+.bucket.meta.im-core-prd-aa-s100-30:mzone.1461106.2611 to cache LRU end
2016-06-22 11:40:17.640138 2b067aa0e700 10 chain_cache_entry: cache_locator=.rgw+im-core-prd-aa-s100-30
2016-06-22 11:40:17.640138 2b067aa0e700 10 chain_cache_entry: cache_locator=.rgw+im-core-prd-aa-s100-30
2016-06-22 11:40:17.640140 2b067aa0e700 10 chain_cache_entry: cache_locator=.rgw+.bucket.meta.im-core-prd-aa-s100-30:mzone.1461106.2611那我
异常分析：
异常点分析1：
在bucket创建失败后再次创建的情况下，日志显示：
cache_map中对应bucket的mzone元数据，名字存在，但对应的cache 实体信息为全0（怀疑，因为flags=0）
所以，引用cache put操作来更新它的mzone元数据时，因为entry里面的lru_iter指针的值实际上是0，代表NULL，与
lru中记录的lru.end不等
故而调用了对应的moving方法而不是adding方法
调用moving方法的时候，因为lru是list<string>结构，先对其（原来的信息--原来的entry.iter执行的那个name做了）做移除，
再将新的name加入的lru队列
但是由于，entry.iter实际上是NULL，所以并没有移除什么东西，而name实实在在是加入了lru，不过lru.size的值却没有因此增加
就会出现lru记录的长度和实际的长度不等的情况。而adding操作的话不会出现这种情况。
修复方法1：
用list.contain判断lru中是否有该对象，有的话再删除：
list.contains("对象name"))
修改后代码：
函数：void ObjectCache::touch_lru
原代码：
else
{
ldout(cct, 10) << "moving " << name << " to cache LRU end" << dendl;
lru.erase(lru_iter);
lru.push_back(name);
lru_iter = lru.end();
--lru_iter;
}
修改后：
else
{
ldout(cct, 10) << "moving " << name << " to cache LRU end" << dendl;
if(lru.contains(lru_iter))
{
lru.erase(lru_iter);
lru_size--;
}
lru.push_back(name);
lru_iter = lru.end();
lru_iter--;
lru_size++;
}
//lru.end不一定是NULL
修改目的： 保证lru的size和实际内容协调。如果lru_iter是空，那么就完全相当于新增。
但是这也不是问题的关键。
关键是，当lru_iter是空的时候，不应该将指针传入cache_lru函数，所以，需要改：
而且指针的++和--操作的安全性也没有判断啊）
在ObjectCache::touch_lru函数的去重操作后,adding或moving前，加入地址指针有消息判断：
if(lru_iter == NULL)
{
ldout(cct,20) << "ERR! entry name="<<name<<"iter is empty"<<endl;
return;
}
异常分析2：
异常1出现的本质原因是cache_map中，mzone对应的name的实体entry是全0(怀疑），所以，排查cache_map中entry填充信rgw_cache_lru_size息。
那么，就是mzone的放入cache_map出了问题。。
放入：
1. cache put
放入lru_iter的信息正常情况是lru的末尾指针，
异常的话，如果cache_map中有值，但为0，就不等于end
entry就会是这个0，就是cache_map中有，但是全0
第一次：
指针=lru的end，经过touch_lru后，指向lru的尾部，如果为0，说明，lru的尾部就是0了
注意：list的end指向的不是NULL（可以不是），而是list中末尾元素的下一个，
而end地址--就是末尾信息
异常分析3：
lru_size与lru信息长度不一致时，会出现什么情况：排查：
1.touch_lru的去重过程中，若总长度大于配置长度rgw_cache_lru_size（默认1000）时，触发！
操作：当lru_size大于设置值，并且，当前lru指针（从头/最旧的开始）不等于需要加入的name指针，那么修建cache_map，这里因为iter是从lru里面取出来的，做pop_front的时候，倒是真的可以不用判断的。
然而lru_size除了此次外，并没有做循环变量用，所以应该不会造成危害。
问题：
如果name还有需要处理的项，也就是在name之前的，但是没有有效使用（）
比如存盘，比如其他处理，怎么办？这就被清理了？
定位方式：
全局查找：removing entry: name=看有没有对应的name
。。。。。
正常情况下，cache_map中的mzone应该已经存在了，那么，get的时候，获取name对应的entry就是存在的。
//int ObjectCache::get(string& name, ObjectCacheInfo& info, uint32_t mask, rgw_cache_entry_info *cache_info)
待改进3：
cacahe中写入和修改元数据的时候有日志，怎么写入说数据的时候不打日志啊
日志啊。。很重要的啊
定位到：
写入数据的时候，已经将name加入了cache map 但是没有将元数据加入
get_obj_ref
---都是本地基本操作，失败的概率小，因为没有特定性，如
pool_create
open_bucket_pool_ctx
只可能是IO或者POOL创建失败
而且返回值=不存在-EONET
最大可能性：
ObjectReadOperation操作执行失败
返回值=不存在
rgw_rados_ref.ioctx.operate
*****************************
create_bucket
get_bucket_info
在循环中，必然是get_bucket_entrypoint_info
中返回的，但是该函数在之前被其他流程调用过
在获取实例信息的时候是OK的
get_bucket_instance_from_oid
get_bucket_instance_from_oid
rgw_get_system_obj
step1 int ret = rop.stat(objv_tracker);
if (ret < 0)
return ret;
store->stat_system_obj
RGWRados::get_obj_state_impl
raw_obj_stat
if (r == -ENOENT)
{
s->exists = false;
s->has_attrs = true;
s->mtime = 0;
return 0;
}
step2 因为在enoent的情况下，返回的是0，所以继续read
ret = rop.read(0, request_len - 1, bl, objv_tracker);
进入get_system_obj第一步：执行get_obj_state
失败，返回
stat_system_obj在astate的exists为false的时候，也会返回enoent，所以。。这样也可以，可能会。。。
get_bucket_entrypoint_info
调入