This issue is about making TarMK gc more scalable:
- how to deal with huge repositories.
- how to deal with massive concurrent writes.
- how can we improve monitoring to determine gc health.
- Monitor deduplication caches (e.g. deduplication of checkpoints)
Possible avenues to explore:
- Can we partition gc? (e.g. along sub-trees, along volatile vs. static content)
- Can we pause and resume gc? (e.g. to give precedence to concurrent writes)
- Can we make gc a real background process not contending with foreground operations?
This issue is a follow up to
OAK-2849, which was about efficacy of gc.