Quota follow up: Buddy group accounting mode, refactoring, logging - #78
Open
rustybee42 wants to merge 7 commits into
Open
Quota follow up: Buddy group accounting mode, refactoring, logging#78rustybee42 wants to merge 7 commits into
rustybee42 wants to merge 7 commits into
Conversation
rustybee42
changed the title
rustybee42
force-pushed
the
rb/quota-followup
branch
from
August 14, 2026 07:30
df65b89 to
ac22609
Compare
* Quota: Log information after the operations are completed with more information at info level, remove the not so useful initial debug logs * Promote and improve some other state logging
Required to get newest the newest sqlite, which allows adding constraints using ALTER TABLE
Before, targets in buddy groups would count double towards the limits as quota would just use the data from both. Now, only the primary target is taken into account by default. This has the consequence that potentially unmirrored data present on the secondary will not be counted towards the quota anymore. And, if there is a switchover, the numbers might suddenly change. We assume though, that most customers have exclusive mirrored targets. To get the old behavior, the accounting mode is stored with the buddy groups and can be set via ctl. On updating management (from 8.x), it will use the old behavior, adding new groups uses the new behavior. Upgrading from v7 uses the new behavior as this usually makes more sense and is already a breaking change. * Also add modify_buddy_group() handler to change the accounting mode and adapt the create_buddy_group() and get_buddy_groups() handlers * Refactor the get_buddy_groups() big sql query, using string for selecting columns
Test the accounting modes, making sure they work as expected + more.
rustybee42
force-pushed
the
rb/quota-followup
branch
2 times, most recently
from
August 17, 2026 10:48
4065ad3 to
1c3b28e
Compare
* Add a new associated const to the Msg trait that defines how long to wait for this message when receiving it as a response. To achieve this, make the timeout setting for stream writes and reads a function argument and pass the message specific time limit. * Set/increase the default to 5s as there is no real disadvantage to wait a bit longer for responses, just in case. * For GetQuotaInfoResp, set this to 1m. Querying the maximum of ~167k quota entries per request can take some seconds, according to some quick benchmarks. This should be plenty of room for slower systems/disks. * When reading a response, also use the per-message time limit for the body * Separately set the connect time limit to 2s to avoid waiting too long for fallbacks * Increase the "generic" stream timeouts to 5s. * Limit the concurrent quota requests to half the maximum outgoing connections. This prevents quota requests eating up all the connections and blocking other operations if responses take a long time to arrive. * Make sure the connection limit setting is at least 1 * Renaming to match the term "time_limit"
* fetch_and_update() doesn't error out anymore on inner errors, always processing all tasks. This prevents running tasks getting detached and potentially keep running during the next fetch, allowing more concurrent connections being used for quota than the semaphore allows. * Error out if any ids were configured (no all mode) but none were resolved (e.g. by providing an empty id file) * Fix various small issues and redundancies * Add some commentary
rustybee42
force-pushed
the
rb/quota-followup
branch
from
August 17, 2026 12:40
1c3b28e to
786e0d2
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See commits.
Depends on ThinkParQ/protobuf#78 (TODO: Update protobuf ref)
Related to https://github.com/ThinkParQ/beegfs-core/issues/4794