Decouple expired object collector from epoch ticker #1482

New issue

Closed

opened 2025-12-28 17:23:09 +00:00 by sami · 0 comments

sami commented

2025-12-28 17:23:09 +00:00

Owner

Originally created by @roman-khimov on GitHub (Aug 12, 2025).

Originally assigned to: @End-rey on GitHub.

I'm always frustrated when I'm thinking of how expired objects are handled (and even more frustrated when I'm fixing thing as in #3511):

expired objects are just another sort of garbage
there can be 1M or more objects expired in an epoch
marking them as garbage separately from deletion just adds useless pressure to metabase

Describe the solution you'd like

Move their handling from epoch event handler to regular GC cycle. Epoch event just sets some known epoch and that's it.
Grab a number of them (same limit as in GC) when doing regular GC cycle.
Handle them as usual, if we find that some object shouldn't be deleted (a lock is stored on the other shard), copy this lock to current shard.

Describe alternatives you've considered

No alternatives.

Originally created by @roman-khimov on GitHub (Aug 12, 2025). Originally assigned to: @End-rey on GitHub. ## Is your feature request related to a problem? Please describe. I'm always frustrated when I'm thinking of how expired objects are handled (and even more frustrated when I'm fixing thing as in #3511): * expired objects are just another sort of garbage * there can be 1M or more objects expired in an epoch * marking them as garbage separately from deletion just adds useless pressure to metabase ## Describe the solution you'd like 1. Move their handling from epoch event handler to regular GC cycle. Epoch event just sets some known epoch and that's it. 2. Grab a number of them (same limit as in GC) when doing regular GC cycle. 3. Handle them as usual, if we find that some object shouldn't be deleted (a lock is stored on the other shard), copy this lock to current shard. ## Describe alternatives you've considered No alternatives.