Agree. While the name might be misleading, it indeed accurately reflects the actual disk usage situation.
BR On Wed, Mar 27, 2024 at 3:48 PM Girish Sharma <scrapmachi...@gmail.com> wrote: > > Hi Xiangying, > > > > In the current implementation, the backlog size is estimated from the > > mark delete position to the last confirm position, whereas the backlog > > message count is the number of messages from the mark delete position > > to the last confirm position, minus the count of individually > > acknowledged messages. The inconsistency between these two could > > potentially confuse users. > > > > While confusing, it is somewhat accurate. Since the messages can be part of > the same ledger where some messages are acked, some aren't, we can't delete > that entire ledger until all messages of the ledger are acked - so it does > contribute towards size of the backlog from a disk perspective. > There might be some optimization possible - in a way that we try to figure > out all completely acked ledgers from markDeletePosition to latest offset > and remove their size, but what's the ROI there? > > So I would say that in your proposal, option 2 (current) is more accurate > (while not being the best) than option 1. > > Regards > -- > Girish Sharma
