Last active
October 21, 2021 01:12
-
-
Save keithchambers/80b60559ad83cebf1672 to your computer and use it in GitHub Desktop.
Ansible role to set 'noop' i/o scheduler (CentOS 7)
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
--- | |
- name: test if grub configured for noop i/o scheduler | |
command: egrep -q 'elevator=noop' /boot/grub2/grub.cfg | |
register: grub | |
changed_when: no | |
failed_when: grub_test.rc == 2 | |
- name: configure grub for noop i/o scheduler | |
sudo: yes | |
command: grubby --update-kernel=ALL --args=elevator=noop | |
when: grub_test.rc == 1 | |
- name: get list of block devices to test | |
shell: ls /sys/block/ | egrep '^([shv]|xv])d[a-z]$' | |
register: block_devs | |
changed_when: no | |
- name: test if block device using noop i/o scheduler | |
shell: cat /sys/block/{{ item }}/queue/scheduler | egrep -q '\[noop\]' | |
with_items: block_devs.stdout | |
register: noop_test | |
changed_when: noop_test.rc == 1 | |
failed_when: noop_test.rc == 2 | |
- name: set block device to use noop i/o scheduler | |
sudo: yes | |
shell: echo noop > /sys/block/{{ item }}/queue/scheduler | |
with_items: block_devs.stdout | |
when: noop_test.changed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Why so complicated to set the current scheduler via
/sys/block/*/queue/scheduler
when this can also be done in a single Ansible task? At least with enabled facts gathering which already does most of the work.I got these variants of that task and they even cope with newer releases requiring
none
instead ofnoop
because it should work with more than just one release of one distro and also with NVMe SSDs:Variant 1 (shortest, but hackish):
Variant 2 (longer, but doesn't require suppressing expected errors):
The only downside (of these two variants) I'm currently aware of is that they say "skipped" instead of "ok" if it is actually already ok.
So I wrote variant 3, based on variant 1:
This correctly says
ok
if it is ok, but it though executes the command. So let's do a variant 4 which also defines when the command actually failed (havingwrite error: Invalid argument'
in STDERR is actually a sign of success in this case):Since I wasn't happy with that error prone looking
failed_when
statement, my final variant is now this one:In you case, this simple variant would likely suffice: