mirror of
https://github.com/scylladb/scylladb.git
synced 2026-06-02 13:06:57 +00:00
15dd76f0c2
Fixes #8363 Delete segements has two issues when running with size-limited commit log and strict adherence to said limit. 1.) It uses parallel processing, with deferral. This means that the disk usage variables it looks at might not be fully valid - i.e. we might have already issued a file delete that will reduce disk footprint such that a segment could instead be recycled, but since vars are (and should) only updated _post_ delete, we don't know. 2.) It does not take into account edge conditions, when we only delete a single segment, and this segment is the border segment - i.e. the one pushing us over the limit, yet allocation is desperately waiting for recycling. In this case we should allow it to live on, and assume that next delete will reduce footprint. Note: to ensure exact size limit, make sure total size is a multiple of segment size. Fixed by a.) Doing delete serialized. It is not like being parallel here will win us speed awards. And now we can know exact footprint, and how many segments we have left to delete b.) Check if we are a block across the footprint boundry, and people might be waiting for a segment. If so, don't delete segment, but recycle. As a follow-up, we should probably instead adjust the commitlog size limit (per shard) to be a multiple of segment sizes, but there is risks in that too.