ceph pg_epoch 字段解析

我们常在观察打印时，看见有类似于下面的 pg_epoch 打印信息，所以里面每个字段都代表啥意思呢？本文将逐步拆解

pg_epoch: 10818 pg[36.39s0( v 10762'2312 lc 10762'2311 (0'0,10762'2312] local-lis/les=10814/10815 n=1 ec=9887/9887 lis/c=10814/10814 les/c/f=10815/10815/0 sis=10814) [10,19,3,21,8,17]p10(0) r=0 lpr=10814 crt=10762'2312 lcod 10762'2312 mlcod 0'0 active+clean m=1]

10818：OSDMap的版本号，即 Epoch 号，由OSDMonitor负责生成，总是单调递增    Epoch变化意味着OSDMap发生了变化，需要通过一定的策略扩散至所有客户端和位于服务端的OSD。因此，为避免Epoch变化过快导致OSDMap相关的网络流量和集群存储空间显著增加，导致Epoch消耗过快，一段时间内所有针对OSDMap的修改会被折叠进入同一个Epoch

36.39s0：pg_id，"."之前的数字，代表 pool_id

v 10762'2312：last_update，存储在结构体 pg_info_t 内，last object version applied to store.

lc 10762'2311：last_complete，存储在结构体 pg_info_t 内，last version pg was complete through

(0'0,10762'2312] local-lis/les=10814/10815 n=1 ec=9887/9887 lis/c=10814/10814 les/c/f=10815/10815/0 sis=10814)

0'0：log_tail，存储在结构体 pg_info_t 内，oldest log entry.

10762'2312：last_update，同上面的 v 10762'2312

local-lis/les=10814/10815：last_interval_started，存储在结构体 pg_info_t 内，

n=1：stats.stats.sum.num_objects，存储在结构体 pg_info_t 内，first epoch of last_epoch_started interval

ec=9887/9887 lis/c=10814/10814 les/c/f=10815/10815/0 sis=10814 这一段都是结构体 pg_history_t 内的信息  

再次进行分段拆解：

ec=9887/9887：epoch_created/epoch_pool_created,

epoch_created：epoch in which *pg* was created (pool or pg)

epoch_pool_created：epoch in which *pool* was created

lis/c=10814/10814 ：last_interval_started/last_interval_clean, 

last_interval_started：first epoch of last_epoch_started interval

last_interval_clean：first epoch of last_epoch_clean interval

les/c/f=10815/10815/0 ：last_epoch_started/last_epoch_clean/last_epoch_marked_full , 

last_epoch_started：lower bound on last epoch started (anywhere, not necessarily locally)

last_epoch_clean：lower bound on last epoch the PG was completely clean.

last_epoch_marked_full：pool or cluster

sis=10814：same_interval_since, same acting AND up set since

[10,19,3,21,8,17]p10(0) ：当然代表 pg 所存储的各 osd_id ，第一个为 primary

r=0：role，0 = primary, 1 = replica, -1=none.

lpr=10814：get_last_peering_reset()，epoch of last peering reset

crt=10762'2312：pg_log.get_can_rollback_to()，can_rollback_to

lcod 10762'2312：last_complete_ondisk，last_complete that has committed

mlcod 0'0：min_last_complete_ondisk，min over last_complete_ondisk,peer_last_complete_ondisk

active+clean ： 状态码

epoch：
一般情况下指OSDMap的版本号，由OSDMonitor负责生成，总是单调递增    Epoch变化意味着OSDMap发生了变化，需要通过一定的策略扩散至所有客户端和位于服务端的OSD。因此，为避免Epoch变化过快导致OSDMap相关的网络流量和集群存储空间显著增加，导致Epoch消耗过快，一段时间内所有针对OSDMap的修改会被折叠进入同一个Epoch