The walk is where the cost sits. Deep scrub takes a chunk of 5 to 15 objects and, for each one, steps through OMAP 1024 keys at a time, CRCing the header and then every key and every value while counting keys and summing value lengths [9][8]. Only after the walk does it compare against the two thresholds [10]. An object sitting at the default 200000-key threshold takes 196 of those steps before the comparison happens, because 200000 divided by 1024 is 195.3 [24].
Two details change how the warning text reads. "Size (bytes)" sums value lengths only, so the 1073741824-byte default is 1 GiB of values with no key bytes counted, and an object full of keys with empty values is reported at size 0 [15][27]. And `omap_checks()` stops at the first flagged object in each chunk, so a chunk holding several large objects contributes one [17]. At the default upper chunk size of 15, the count in "N large objects found in pool 'X'" can be short by a factor of 15 [26][13].
There is a boundary the source states twice and not identically. The comparison is strictly greater-than, so exactly 200000 keys is not large [16], yet the same list offers an object with 200000 keys and empty values as its example of tripping the key threshold [15]. By the rule as written, 200001 is the first large key count.
`scrub_finish()` assigns `num_large_omap_objects`, `num_omap_keys` and `num_omap_bytes` only when the scrub was deep, and nothing on the write path moves them [12][18]. Growth that lands just after a PG's deep scrub waits for the next one, which on the default interval is close to seven days of silence [28].
The published material stops short of the measurements. The stated questions include whether the OSD keeps a live per-object OMAP size anywhere queryable, which of `ceph pg dump`, `ceph df detail`, `ceph osd df`, the OSD admin socket and the Prometheus module return live numbers rather than scrub-time snapshots, what `rados listomapkeys | wc -l` costs on the OSD, and whether a supported top-N-by-keys query exists [23]. The text ends at the lab setup [29]. This evidence leaves the cost side of the early-detection techniques unresolved. The cluster is three hosts, six BlueStore OSDs, replicated size 3, running 20.2.3 Tentacle daemons under cephadm, with a single-PG test pool and autoscaling off [19][22]. Six OSDs and one PG amounts to a way to watch a deep scrub finish while you are still at the terminal, rather than a capacity test. No RGW was deployed, and `radosgw-admin` was present only to confirm command availability [20], so the bucket index question was never put to a live index.
The answer that is in the code is a design pattern. The MDS open file table caps entries per object at exactly `osd_deep_scrub_large_omap_object_key_threshold` and spreads the rest across up to 1024 objects [7], which at the default default puts its ceiling at 204,800,000 entries [25]. That is shard-at-the-application-layer, chosen by the people who wrote the check. It also means raising the OSD threshold to quiet the warning silently enlarges every MDS open file table shard, because the MDS reads the same option [7].
