tree 21e2ac193c5673201bfcf06470946f91bf2a5a31
parent 1ae510dcda369b7a744945ab9d61e242c7b0e941
author Kevin Wilson <klwilson227@comcast.net> 1617259364 -0600
committer GitHub <noreply@github.com> 1617259364 +0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJgZWtkCRBK7hj4Ov3rIwAAdHIIAKce9G+BPW8Jg3MyVg7DmBhI
 d2HZBGKrK8At5eMBy1g2AMpNtS6HXJRvDNqNGXeUg4TFv26w/t+mOL9wQE05z+1g
 O1vTOp1udvvok3cLw5orShIye5NxyRR2zX+CHrmTLVXVVwnxFZ8tpSVqummU9MhE
 SHabDXIo1BbH8yrd5KP1mW7IUcSbW294nMh0ZLnQG44QDS90ImUh7N507fBPvcbg
 x85Z4vp+nikP6MkwETLFHxglqWa6B6Zfa4mSo1RGTe2z3qeGiMxP51i8mNmmZPPj
 DkGJshBvWUKBbMrZcSSH6UjkmQ+zUw4tA6EQgEfCeSHO2j2mL9GYUVJSyO7b0zk=
 =vcrK
 -----END PGP SIGNATURE-----
 

Defect-Fix Compaction status report into correct buckets. (#2645)

The compaction status report is off by 1.

When compaction is enabled, the 10% log is always empty. Setting the compaction threshold to .2 we were seeing the number of compacted entrylogs that were removed, match the sum of the 20% and 30% buckets. While the 10% bucket remained empty. Increasing the threshold to .3 we would see the sum of the first 4 buckets compacted (10%-40%). Also with the 10% bucket empty.

Upon inspection of the code, the code is using the .ceil function to calculate the bucket index to be updated. This means that 10% bucket will never be used. However, there could be a rare 100% case in which the code runs into a index out of bounds exception when the entrylog is actually 100% used. The index calculation should be using floor and not the ceil call using the next index lower. So usage of .00 to .9 ends up in the 0 index instead of the current calculation which puts the .0 - .9 in the 1 index.

This will leave the 100% index empty most of the time, as rarely will the entry logs be 100% used.