Hi Christo, We're not adding new stuff to ZK at this point (it's deprecated), so it would be good to drop that from the design.
With regard to the "saturated" state: I'm skeptical that compaction could really move the needle much in terms of freeing up space -- in most workloads I've seen, it wouldn't. Compaction also requires free space to function as well. So the main benefit of the "satured" state seems to be enabling deletion on full disks. But KRaft mode already has most of that benefit. Full disks (or, indeed, downed brokers) don't block deletion on KRaft. If you delete a topic and then bounce the broker that had the disk full, it will delete the topic directory on startup as part of its snapshot load process. So I'm not sure if we really need this. Maybe we should re-evaluate once we have JBOD + KRaft. best, Colin On Mon, May 22, 2023, at 02:23, Christo Lolov wrote: > Hello all! > > I would like to start a discussion on KIP-928: Making Kafka resilient to > log directories becoming full which can be found at > https://cwiki.apache.org/confluence/display/KAFKA/KIP-928%3A+Making+Kafka+resilient+to+log+directories+becoming+full > . > > In summary, I frequently run into problems where Kafka becomes unresponsive > when the disks backing its log directories become full. Such > unresponsiveness generally requires intervention outside of Kafka. I have > found it to be significantly nicer of an experience when Kafka maintains > control plane operations and allows you to free up space. > > I am interested in your thoughts and any suggestions for improving the > proposal! > > Best, > Christo
