Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 530
    • Issues 530
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 100
    • Merge requests 100
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #3327

Closed
Open
Created May 05, 2022 by Evan Hunt@eachOwner

fetches-per-server has been broken since 9.16

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.

Assignee
Assign to
Time tracking