Benedict - I’ll reply more directly to the other sections. > Another thing to balance is whether this complexity is justified for a > stop-gap measure, if we expect this to be made defunct by both Branimir's new > file format
I don’t think the incremental complexity here is that great. It is unfortunate that a new file format is required, as I mentioned previously, but not all file formats are equal complexity (nor equal payoff). The new format here strikes a reasonable balance that will appeal to enough users. > have we explored simply removing anti-compaction instead CEP-45: Mutation Tracking aims to be that exploration. I do not see a problem with multiple solutions competing for our users’ problems; if Mutation Tracking arrives first and appeals to users, so be it. I personally would be more wary of experimenting with a new version of incremental repair that didn’t do anti-compaction, compared to a new file format but the same state machine. On Thu, Oct 1, 2026, at 6:07 PM, Benedict Elliott Smith wrote: > Hi Chris, > > Did you miss my email[1] on the DISCUSS thread? Abe partially responded > to it, and I found his answer to this part satisfactory, but I would > appreciate discussing the remaining items before we move to a VOTE. > > Thanks > > https://lists.apache.org/thread.html/07c52dv46xk4hynknfb42kkh424r3o1y > > On 2026-09-28 20:40 UTC Chris Lohfink wrote: >> I'd like to call a vote on CEP-66: Zero-copy SSTable splitting. >> >> The proposal splits eligible compressed SSTables by reusing their encoded >> compression chunks and rebuilding the child components, avoiding a row >> rewrite. It starts with an opt-in sstablesplit --zero-copy mode for split >> tool and BIG-format SSTables on Cassandra 7.0/trunk. Reflinks provide an >> additional optimization where supported; otherwise, Cassandra copies the >> encoded bytes. Follow-up incremental phases cover Spark support, >> anticompaction, BTI, 2i, and partial-range zero copy streaming. >> >> The discussion covered the new SSTable format, compatibility, reflink >> complexity, and digest generation. The proposal and discussion are here: >> >> Proposal: >> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/451972773/draft+CEP-66+Zero-copy+SSTable+splitting >> <https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/451972773/draft+CEP-66+Zero-copy+SSTable+splitting> >> >> Discussion: >> https://lists.apache.org/thread/sjqbv0m451kqopms8whymgwbrr2v16tw >> <https://lists.apache.org/thread/sjqbv0m451kqopms8whymgwbrr2v16tw> >> >> Please cast your vote in this thread. The vote will remain open for at >> least 72 hours, longer if needed. Per the CEP process, adoption requires >> three binding +1 votes and no binding vetoes. >> >> Thanks, >> Chris >>
