]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph-ci.git/commit
rgw/lc: At least wait for |rgw_lc_lock_max_time| while trying to fetch the lc-shard...
authorkchheda3 <kchheda3@bloomberg.net>
Fri, 19 Sep 2025 20:05:55 +0000 (16:05 -0400)
committerMatt Benjamin <mbenjamin@redhat.com>
Thu, 9 Oct 2025 15:15:51 +0000 (11:15 -0400)
commit84df008dc96d1403765e16ae4a393e50b4ac4d86
tree8a547225a29f30347fe02a0afc9cbe9e55459b9d
parent09ad10d91aaf6cd6dfd36afe56fa47d03915917c
rgw/lc: At least wait for |rgw_lc_lock_max_time| while trying to fetch the lc-shard lock to get or update the bucket status.

Currently each lc worker would try 1 second to get the lock on lc_shard to decide on which bucket to process and again 1 second to update the bucket status once bucket is lc processed. However when there are multiple rgws running lc, often shard is locked by the other lc worker or if there are issues when the rados is slow the lock is not processed within 1 second and worker either skips processing the bucket or skips updating the bucket, resulting in miss of LC or miss in updating the bucket status.
So in worst case when other lc worker is already processing a shard, wait for rgw_lc_lock_max_time to get the lock, as any given worker can max hold onto rgw_lc_lock_max_time a given shard.

Fixes: https://tracker.ceph.com/issues/72572
Resolves: rhbz#2401203

Signed-off-by: kchheda3 <kchheda3@bloomberg.net>
(cherry picked from commit 937ac626afd3bf443edf96aa177854e8eb291af5)
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
src/rgw/rgw_lc.cc