min time, deletion is lazy – can occur at some
> > > (distant?)
> > > > time in the future (and is async I think) – this was particularly
> > > > noticeable for tiered storage (only time I’ve really understood how
> > Kafka
> > > > segments work
ered storage (only time I’ve really understood how
> Kafka
> > > segments work and looked closely), Paul
> > >
> > > From: Matthias J. Sax
> > > Date: Tuesday, 25 February 2025 at 1:16 pm
> > > To: users@kafka.apache.org
> > > Subject:
> time in the future (and is async I think) – this was particularly
> > noticeable for tiered storage (only time I’ve really understood how Kafka
> > segments work and looked closely), Paul
> >
> > From: Matthias J. Sax
> > Date: Tuesday, 25 February 2025 at
iceable for tiered storage (only time I’ve really understood how Kafka
> segments work and looked closely), Paul
>
> From: Matthias J. Sax
> Date: Tuesday, 25 February 2025 at 1:16 pm
> To: users@kafka.apache.org
> Subject: Re: Documentation and meaning of configuration 'ret
tiered storage (only
time I’ve really understood how Kafka segments work and looked closely), Paul
From: Matthias J. Sax
Date: Tuesday, 25 February 2025 at 1:16 pm
To: users@kafka.apache.org
Subject: Re: Documentation and meaning of configuration 'retention.bytes'
EXTERNAL EMAIL - U
I think you are right. Technically, it's a "minimum" not a "maximum".
The cleanup happens async by the background log-cleaner thread. Segments
which go beyond the "retention.bytes" config can be removed.
I think it's just a difference between "technically correct" (ie,
engineering / nerd lang
Hi,
I encountered a misunderstanding and I would like you to explain it to me
or if possible change the documentation.
The Kafka docs describes 'retention.bytes' configuration as:
This configuration controls the maximum size a partition (which consists of
log segments) can grow to before we will d