Skip to content

Conversation

@oleiman
Copy link
Member

@oleiman oleiman commented Dec 22, 2025

builds on

Backports Required

  • none - not a bug fix
  • none - this is a backport
  • none - issue does not exist in previous branches
  • none - papercut/not impactful enough to backport
  • v25.3.x
  • v25.2.x
  • v25.1.x

Release Notes

  • none

@oleiman oleiman self-assigned this Dec 22, 2025
@oleiman oleiman force-pushed the ct/core-15022/sharded-gc-workers branch 2 times, most recently from 72eaa03 to 0e7696d Compare December 27, 2025 22:09
@oleiman oleiman force-pushed the ct/core-15022/sharded-gc-workers branch from 0e7696d to ef51053 Compare January 16, 2026 00:55
By default cloud_io::remote::list_objects is greedy. In this case, we want to
control paging in the garbage collector.

Signed-off-by: Oren Leiman <[email protected]>
The control loop doesn't need to know about the rest of the list_objects
response on the happy path, except if an error occurred.

This will make it easier to change the source of those bucket items when/if
we add some caching.

Signed-off-by: Oren Leiman <[email protected]>
Includes plumbing self node ID & members_table down into level_zero_gc

Signed-off-by: Oren Leiman <[email protected]>
@oleiman oleiman force-pushed the ct/core-15022/sharded-gc-workers branch 2 times, most recently from 97ec718 to 6bf7fcd Compare January 16, 2026 07:49
Gives the range of random prefixes assigned to this node by dividing prefix
space up according to the total number of shards in the cluster and assigning
a range to each shard based on index from lowest node ID value.

Signed-off-by: Oren Leiman <[email protected]>
- list_objects
- filter on assigned prefix range
- report back to caller whether we've gone past our assigned max prefix

The general idea here is to hide the details of prefix filtering from the
control loop. This is where, ultimately, we'll want to wire in some kind
of local cache for known outstanding garbage.

Signed-off-by: Oren Leiman <[email protected]>
In a loop:
  - try to get the next page
  - if an error occurs, bail
  - if the result is non-empty, return the objects
  - otherwise do_next_page reports whether or not we have passed the
    maximum assigned prefix for this shard
    - if so, stop iterating, there are definitely no more objects we care about
      in the bucket
    - if not, we have _not yet_ reached the minimum assigned prefix, so we
      should keep paging through the bucket

This is not very efficient if the number of objects in the bucket grows very
large. Alternatives include:

- caching bucket contents
- listing on assigned prefixes only

Signed-off-by: Oren Leiman <[email protected]>
Needs cleanup, but basically simulates multi-shard prefix space partitioning.

Signed-off-by: Oren Leiman <[email protected]>
@oleiman oleiman force-pushed the ct/core-15022/sharded-gc-workers branch from 6bf7fcd to 07d7742 Compare January 17, 2026 01:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant