Ceph » RADOS

The way to reproduce it is
1. create a large omap object (more than 1gb)
2. do deep-scrub of the PG which contains that object.
3. large omap object count will 1(check `ceph health detail`)
4. Shutdown the primary osd which has control over that PG.
5. Some secondary osd will take control over, check the health detail again, warning will be gone.

A better way to identify this problem is logging in OSD::collect_pg_stat. When we created a larget omap object, it will be shown in pg stat of primary osd that large omap object count is 0. After deep-scrub it will be 1. If we shutdown the primary osd, then if we check the log of new primary osd we will get 0 in the pg stat of that pg.

root cause of the problem when we do some changes in the object then primary osd submit some transaction through `void ReplicatedBackend::submit_transaction` function which eventually call `Message * ReplicatedBackend::generate_subop`there it ships transaction including pg stat and log entries. But for deep-scrub even if it changes the pg stat of primary osd but it does not publish that pg stat to other osds.

Solution could be create some mechanism such that we can publish the pg stat to the non-primary osd after deep-scrub.
I am able to reproduce it in quincy v17.2.7 but other versions will have the problem as well.