/claim #4297

All Submissions:

• Contributions should target the dev branch. Did you create your branch from dev?
• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

What this does is checks if there is twice as much free space on the volume as what the collection being optimized already takes.

I'm not happy with this, and I'm not sure this submission worth the hassle as it is, but I'd like to compare opinions.

Why it's bad

• The free space checking works synchronously; even though the optimizations themselves take up background threads, I feel uneasy about it.
• The checking happens in the moment the optimization is about to start, not well beforehand.
• We still might run into OOD down the line because FS is non-atomic.
• It still logs the error, perhaps we want to special-case it as we do with CollectionError::Cancelled.

What else have I tried

• Capture write error from db.put_cf_opt; it first happens somewhere around lib/segment/src/segment_constructor/segment_builder.rs:197, but I could not find a way to cleanly rollback a partially done optimization.
• Utilize the existing DiskUsageWatcher to do the checking before the optimization starts, but it does not have a dynamic threshold, so far as I understand it, and overall it gets a larger change that doing how it's done now.
• Add a method check_environment to the trait SegmentOptimizer in the same spirit as the existing SegmentOptimizer::check_condition so that all the implementors could tailor it to their taste, but for now this approach adds no value.