Tweak rebuild in-flight hard limit #15324
Merged
Conversation
This file contains 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
Vendor testing shows we should be able to get a little more performance if we further relax the hard limit which we're hitting. Authored-by: Brian Behlendorf <[email protected]> Signed-off-by: Tony Hutter <[email protected]>
|
I am trying to understand why would you want to wipe half of ARC for that. Do you have very small ARC or too many top-level vdevs? |
|
While it's definitely borderline, where we bumped up against this limit was with a pool with two top-level 50-device dRAIDs and a top-level special device mirror. That limited us to 1/12 of the ARC (1/4 ARC * 1/3 per top-level vdev). Allowing this to be bumped up a bit further speed up the rebuild by ~10%. Whether giving up that much ARC is worth it is a harder call, and I wouldn't want to change the defaults, but bumping up the hard limit seems reasonable. |
amotin
approved these changes
Sep 29, 2023
behlendorf
added
Status: Accepted
behlendorf
added a commit
to behlendorf/zfs
that referenced
this pull request
Sep 29, 2023
Vendor testing shows we should be able to get a little more performance if we further relax the hard limit which we're hitting. Authored-by: Brian Behlendorf <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Tony Hutter <[email protected]> Closes openzfs#15324
behlendorf
added a commit
that referenced
this pull request
Oct 3, 2023
Vendor testing shows we should be able to get a little more performance if we further relax the hard limit which we're hitting. Authored-by: Brian Behlendorf <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Tony Hutter <[email protected]> Closes #15324
lundman
pushed a commit
to openzfsonwindows/openzfs
that referenced
this pull request
Dec 12, 2023
Vendor testing shows we should be able to get a little more performance if we further relax the hard limit which we're hitting. Authored-by: Brian Behlendorf <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Tony Hutter <[email protected]> Closes openzfs#15324
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation and Context
Vendor testing shows we should be able to get a little more performance if we further relax the hard limit which we're hitting.
Description
Allows
zfs_rebuild_vdev_limitto be manually tuned to a larger value to get a little more performance on large systems.How Has This Been Tested?
Locally tested by comparing total rebuild times with various settings for
zfs_rebuild_vdev_limit. The default value remains unchanged.Types of changes
Checklist:
Signed-off-by.