last_epoch_started

info.last_epoch_started记录一个激活周期e对于间隔i使得所有在i或更早提交的写入都反映在i之后反映在本地info.last_epoch_started获得一个权威的日志/信息，其中包含一个较旧的info.last_epoch_started独立，因为任何间隔中都没有写入可以提交（参见 PG::proc_master_log）。

info.history.last_epoch_started记录 PG 整体最近活跃并接受写入的间隔的下限。在特定的 OSD 上，它也是本地 PG 日志中发生的写入的激活周期的上限：我们在接受写入之前更新它。因为所有提交的写入都是由所有行动集中的 OSD 提交的，任何非发散的写入确保了history.last_epoch_started在间隔中的所有行动集成员中都记录了。一旦对每个间隔中的 OSD 进行了查询，回到某个已看到的history.last_epoch_started，那么在 maxhistory.last_epoch_started之后的任何间隔都不可能报告写入为已提交（因为我们记录它之前记录了间隔中的客户端写入）。因此，所有信息中last_update的最小info.last_epoch_started >= MAX(history.last_epoch_started)必须是对客户端报告的写入的上限。

我们使用初始激活消息更新info.last_epoch_started，但我们只在新的history.last_epoch_started持久化后（可能连同第一个写入一起）更新info.last_epoch_started。这确保了我们不需要具有最新info.last_epoch_started的 OSD，直到所有行动集中的 OSD 都记录了它。

In find_best_info，我们确实在计算info.last_epoch_started值，因为我们不希望指定一个发散的日志条目，在先前的间隔中它将是非发散的，因为它可能被用来服务读取。在max_last_epoch_started_found时包括activate()中，我们使用对等的last_epoch_started值作为发散日志条目可以追溯到多远的界限。

然而，在像

calc_acting osd.0 1.4e( v 473'302 (292'200,473'302] local-les=473 n=4 ec=5 les/c 473/473 556/556/556
calc_acting osd.1 1.4e( v 473'302 (293'202,473'302] lb 0//0//-1 local-les=477 n=0 ec=5 les/c 473/473 556/556/556
calc_acting osd.4 1.4e( v 473'302 (120'121,473'302] local-les=473 n=4 ec=5 les/c 473/473 556/556/556
calc_acting osd.5 1.4e( empty local-les=0 n=0 ec=5 les/c 473/473 556/556/556

这样的情况下，因为 osd.1 是唯一记录 info.les=477 的，而 osd.4、osd.0（在那个间隔中的行动集）没有记录（osd.4 重启，osd.0 没有及时收到消息），当 osd.4 或 osd.0 中的任何一个都是有效选择时，PG 被标记为不完整。为了避免这种情况，我们在计算info.les时不考虑不完整的对等方。它不曾在行动集中，所以我们必须从那个间隔中必须有另一个 OSD（如果min_last_epoch_started_found. It would not have been in the acting set, so we must have another OSD from that interval anyway (if maybe_went_rw）。如果那个 OSD 不记得info.les，那么我们

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.