Ceph中对象的内涵和语义

对象的内涵和语义

所有ObjectStore中的对象被确定为一个包含在具名集合（coll_t）中的具名对象（ghobject_t和hobject_t）。ObjectStore的操作支持创建，变化，删除以及在集合中枚举对象。枚举是以键为顺序的（其中键由哈希排序）。对象名称是全局唯一的。

每个对象有四个不同的部分：byte data（数据）, xattrs（扩展属性）, omap_header and omap entries（OMAP数据）。

DATA是对象的一部分，概念上等同于文件系统中的文件，而且必须具有随机和局部读写操作。数据稀疏分布有利于某些类型的工作负载，但不是必需的。对于对象有一个系统级的限制是，一个对象最大约为100 MB左右。

XATTR相当于文件系统中的扩展属性。 扩展属性是一组键/值对。次值访问不是必需的。能够以键的顺序列举扩展属性。在具体实现层面，扩展属性只被Ceph系统内部使用，具体实现者可以预期到一个对象的扩展属性总大小是相对较小的，即，小于64KB。大部分的Ceph操作假定访问暂时相邻对象的扩展属性（最近或不久的将来）是代价较低的（缓存）。

OMAP头部是单独的二进制大数据块。它可以被全量读取或写入。

OMAP表项在概念上与扩展属性一样，但在不同的地址空间。换句话说，XATTR和OMAP的键可以相同，但有不同的值。 枚举XATTR表项时不包括OMAP，反之亦然。OMAP表项的大小和访问特性与XATTRS有很大的不同。特别地，一个OMAP条目的数据部分可能非常大（MBs）。更重要的是，该接口必须支持高效的对OMAP表项的范围查询，甚至当有大量表项时仍然需要保持高效。

集合

集合简单来说就是一组对象。集合有名称（coll_t），并且能够按序列举。像对象一样，集合也有一组XATTRS的。

事务

事务代表一系列的变化操作（原子的?）。

事务生命周期中的三个事件引出三类回调。任何事务可以包含任意数量的回调对象（Context），每个回调对象可以是以下三类回调的任意组合：
 on_applied_sync，on_applied和on_commit。

“on_applied”和“on_applied_sync”在当修改请求对后续的操作为可见时被调用，即，结果是可读的。on_applied和on_applied_sync之间唯一的概念上的差异是各自的回调操作所在的线程和锁环境不同。“on_applied_sync”直接由ObjectStore的执行线程调用，预期可以快速执行，而且不能请求调用环境的任何锁。相反地，“on_applied”被独立的Finisher线程调用，这意味着它可以竞争调用环境的锁。注意，on_applied和on_applied_sync是有时也被称为on_readable和on_readable_sync。

“on_commit”回调也被Finisher线程调用，这表示所有的变化已经被持久化到稳定存储中（即现在的naicao的软件/硬件中）。

在实现层面，各个变化原语（还有相关数据）可以被序列化到一个缓冲区。这个序列，当然了，不需要复制的任何数据，但（使用bufferlist库）将引用原缓存区。这意味着这块包含正在被提交数据的缓存区必须被保留到on_commit回调完成时。实际上，bufferlist已经把这一起处理好了，但是如果你通过uffer::raw_static接口引用一个现存的缓存区则需要额外注意。

某些ObjectStore的具体实现选择实现自己的日志形式，其中日志用来记录事务的序列化格式的数据。这要求当事务的编码格式改变后，编码/解码逻辑必须能够正确处理自身的版本和版本升级。这已经发生过几次了，并且事务对象包含一些辅助变量，这些变量可以帮助处理遗留格式的日志数据：

  sobject_encoding检测存在于先前Ceph版本中的OID的旧/简化版本。
  use_pool_override还检测OID可以被先前的操作或缓存覆盖的这种情况。
  对于非遗留的ObjectStore具体实现，这些字段都没什么意义。

事务隔离性

除了以下说明的，隔离是的调用者的责任。换句话说，如果任何的存储元素（存储元素==任何如上所述的对象的四个部分的）是由一个事务（包括删除）改变，则调用者需要承诺当事务未完成时（在这里未完成意味着从事务触发直到“on_applied_sync”被回调）不去读取该元素。隔离性的违反不必由ObjectStore检测，并且没有对应的错误机制来报告隔离性冲突（如果检测到隔离性冲突，崩溃可能是适当的报告方式）。

枚举操作可能违反事务隔离性，正如以上描述，当一个存储元素作为事务的一部分正在被创建或删除，在这种情况下，ObjectStore允许枚举操作可以先与或者后于违背事务的元素执行。换句话说，该正在变化元素可以出现或者不出现在枚举结果中，这完全由ObjectStore的决定。任意排序独立适用于每个事务元素。例如，如果事务包含两个元素的变化，“创建 A”和“删除B”。而在此同时（上述事务还没有完成）进行枚举操作。允许ObjectStore报告任意四种可能的关于A和B是否存在的组合.