在了解Object, Collection, OMap 对象存储 的基本概念,之后大家需要了解文件系统的基本的知识,如transaction, journal等,这里就不详细介绍了。下面具体分析OS模块的代码。
主要的类就是ObjectStore类,其内部有一个重要的transaction类。 JournalingObjectStore继承了ObjectStore的,添加了Journal的功能。FileStore继承了JournalingObjectStore类,实现了在文件中存储。
另一个模块就是Index,在这里实现了两层index,第一层是用来查找collection,第二层是在collection中查找一个object。 其基类为CollectionIndex, LFNIndex 类继承了它,添加了long filename index (LFNIndex)。在第二层index,也就是查找object的index 实现了两类index ,一个是HashIndex, 另一个是FlatIndex,它们都继承了LFNIndex类。其管理功能的就是IndexManager类。
在这里,HashIndex, 指的是在一个Collection的 Object 是层次的结构,说白了,就是当存储对象的目录可以有子目录。而在FlatIndex里,Object 是没有层次结构的,说白了,就是在一个目录中。
我们主要看一个典型的对象操作流程,来看一下内部的操作。
其操作一般是 操作序列号(encode)--> 写入日志(write-journal) --> 写入对象
- t.create_collection(cid);
- cerr << "create collection" << std::endl;
- r = store->apply_transaction(t);
如上图所示是一个典型的对象的操作, 我们在这里大概给出一个内部操作的流程:
1) t.create_collection(cid),
void create_collection(coll_t cid) {
__u32 op = OP_MKCOLL;
::encode(op, tbl);
::encode(cid, tbl);
ops++;
}
其调用了类transaction中的函数,把操作类型和参数通过 encode 函数 序列化到 tbl 中, 我们看到其他的操作都是类型的功能。
2)
store->apply_transaction(t);
这个函数调用了ObjectStore的函数
首先调用
unsigned apply_transaction(Transaction& t, Context *ondisk=0)
其调用 unsigned ObjectStore::apply_transactions(Sequencer *osr,
list<Transaction*> &tls,
Context *ondisk)
最终调用函数
int ObjectStore::queue_transactions(
Sequencer *osr,
list<Transaction*>& tls,
Context *onreadable,
Context *oncommit,
Context *onreadable_sync,
Context *oncomplete,
TrackedOpRef op = TrackedOpRef())
int queue_transactions(Sequencer *osr, list<Transaction*>& tls,
Context *onreadable, Context *ondisk=0,
Context *onreadable_sync=0,
TrackedOpRef op = TrackedOpRef()) {
assert(!tls.empty());
tls.back()->register_on_applied(onreadable);
tls.back()->register_on_commit(ondisk);
tls.back()->register_on_applied_sync(onreadable_sync);
return queue_transactions(osr, tls, op);
}
最后调用了函数
virtual int queue_transactions(
Sequencer *osr, list<Transaction*>& tls,
TrackedOpRef op = TrackedOpRef()) = 0;
这个函数式virturl 函数,其实现在其继承类FileStore类函数中
int FileStore::queue_transactions(Sequencer *posr, list<Transaction*> &tls,
TrackedOpRef osd_op)
核心的处理模块就这这个函数里.
在这个函数里,主要分了两种情况:
1) 有日志处理的逻辑:
if (journal && journal->is_writeable() && !m_filestore_journal_trailing) {
{
Op *o = build_op(tls, onreadable, onreadable_sync, osd_op);
op_queue_reserve_throttle(o);
journal->throttle();
uint64_t op_num = submit_manager.op_submit_start();
o->op = op_num;
if (m_filestore_do_dump)
dump_transactions(o->tls, o->op, osr);
if (m_filestore_journal_parallel) {
dout(5) << "queue_transactions (parallel) " << o->op << " " << o->tls << dendl;
_op_journal_transactions(o->tls, o->op, ondisk, osd_op);
// queue inside submit_manager op submission lock
queue_op(osr, o);
} else if (m_filestore_journal_writeahead) {
dout(5) << "queue_transactions (writeahead) " << o->op << " " << o->tls << dendl;
osr->queue_journal(o->op);
_op_journal_transactions(o->tls, o->op,
new C_JournaledAhead(this, osr, o, ondisk),
osd_op);
} else {
assert(0);
}
submit_manager.op_submit_finish(op_num);
return 0;
}
}
2) 无日志处理逻辑
在int FileStore::_do_transactions 函数里,我们可以看到各种对象的操作,以及如何实现的。
DBMap函数里: omap 保存在一个key/value的数据库里。
LevelDBStore *omap_store = new LevelDBStore(omap_dir);
stringstream err;
if (omap_store->create_and_open(err)) {
delete omap_store;
derr << "Error initializing leveldb: " << err.str() << dendl;
ret = -1;
goto close_current_fd;
}
DBObjectMap *dbomap = new DBObjectMap(omap_store);
ret = dbomap->init(do_update);
if (ret < 0) {
delete dbomap;
derr << "Error initializing DBObjectMap: " << ret << dendl;
goto close_current_fd;
}
attrs 设置在 文件的扩展属性里