Umm, it seems that MemStore requires in memory meta object to keep the
attributes. So it is not a direct way to remove the pg_meta object
backend storage. Any suggestions?
I think we can just skip the pg_meta operation in FileStore api based
on the value of hoid.pgmeta(), not a generic strategy for all
backends.
Regards
Ning Yao
2015-11-18 21:12 GMT+08:00 Sage Weil <sage@xxxxxxxxxxxx>:
> On Wed, 18 Nov 2015, Ning Yao wrote:
>> Hi, Sage
>>
>> pgmeta object is a meta-object (like __head_00000000__2) without
>> significant information. It is created when in PG::_init() when
>> handling pg_create and split_coll and always exits there during pg's
>> life cycle until pg is removed in RemoveWQ. The real content related
>> to pgmeta-data is stored in omap. we may just treat pgmeta-object as a
>> logical object and not present it physically so that we can avoid
>> recursive searching object path by if(hoid.pgmeta())?
>> such as:
>> int FileStore::_omap_setkeys(coll_t cid, const ghobject_t &hoid,
>> const map<string, bufferlist> &aset,
>> const SequencerPosition &spos) {
>> dout(15) << __func__ << " " << cid << "/" << hoid << dendl;
>> Index index;
>> int r;
>> if(hoid.pgmeta())
>> goto out;
>> ***
>> ***
>> ***
>> out:
>> r = object_map->set_keys(hoid, aset, &spos);
>> dout(20) << __func__ << " " << cid << "/" << hoid << " = " << r << dendl;
>> return r;
>> }
>
> This seems like a reasonable hack. We never store any byte data in it.
> And if/when that changes, we can change this at the same time.
>
> sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
