increase disk_erasure_coconcurrency
When we added concurrent disk erasures, we kept the concurrency to 1 as to not risk any different oeprator behavior, at the cost of not faster erasure times. That being said, we have had the setting in place for some time and we have received no reports of issues, so we are incrementing it to four as that should be still quite relatively safe from a concurrency standpoint for disk controllers in systems. Change-Id: I6326422d60ec024a739ca596f46552bbd91b0419
This commit is contained in:
parent
8e57495d10
commit
556d5de9d3
@ -108,7 +108,7 @@ opts = [
|
||||
'state. If True, shred will be invoked and cleaning '
|
||||
'will continue.')),
|
||||
cfg.IntOpt('disk_erasure_concurrency',
|
||||
default=1,
|
||||
default=4,
|
||||
min=1,
|
||||
mutable=True,
|
||||
help=_('Defines the target pool size used by Ironic Python '
|
||||
|
@ -0,0 +1,10 @@
|
||||
---
|
||||
other:
|
||||
- |
|
||||
The maximum disk erasure concurrency setting,
|
||||
``[deploy]disk_erasure_concurrency`` has been incremed to 4.
|
||||
Previously, this was kept at 1 in order to maintain continuity of
|
||||
experience, but operators have not reported any issues with an increased
|
||||
concurrency, and as such we feel comfortable upstream enabling concurrent
|
||||
disk erasure/cleaning. This setting applies to the ``erase_devices`` clean
|
||||
step.
|
Loading…
Reference in New Issue
Block a user