GitLab

While working on another issue I noticed the output of the fetchlimit system test didn't match my recollection of how it used to look. I've almost certainly seen this before, but it didn't rise to the level of consciousness that would prompt me to confirm, but this time it did, and sure enough, up until 9.15.7 the test output looked like this:

I:fetchlimit:checking recursing clients are dropped at the per-server limit
I:fetchlimit:clients: 20
I:fetchlimit:clients: 40
I:fetchlimit:clients: 60
I:fetchlimit:clients: 80
I:fetchlimit:clients: 100
I:fetchlimit:clients: 120
I:fetchlimit:clients: 140
I:fetchlimit:clients: 160
I:fetchlimit:clients: 180
I:fetchlimit:clients: 180
I:fetchlimit:clients: 180
I:fetchlimit:clients: 177
I:fetchlimit:clients: 165
I:fetchlimit:clients: 152
I:fetchlimit:clients: 141
I:fetchlimit:clients: 131
I:fetchlimit:clients: 122
I:fetchlimit:clients: 114
I:fetchlimit:clients: 114
I:fetchlimit:clients: 107

...but now it's this:

I:fetchlimit:checking recursing clients are dropped at the per-server limit
I:fetchlimit:clients: 20
I:fetchlimit:clients: 40
I:fetchlimit:clients: 60
I:fetchlimit:clients: 80
I:fetchlimit:clients: 28
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0
I:fetchlimit:clients: 0

This is due to a logic error introduced in maybe_adjust_quota() in commit bad5a523: Instead of updating the quota to the calculated new_quota, it's updated to ISC_MIN(1, new_quota), which effectively means always 1. The test was only checking that the number of clients was below the specified limit, not that it was above a reasonable minimum, and so the error went unnoticed.

I would guess this has probably had some impact on recursive performance.