2

In CentOS 6, there was /etc/tune-profiles/my-server/ktune.sysconfig with this text(I'm referring to the comments that explain what the code is doing):

# This is the I/O scheduler ktune will use.  This will *not* override anything
# explicitly set on the kernel command line, nor will it change the scheduler
# for any block device that is using a non-default scheduler when ktune starts.
# You should probably leave this on "deadline", but "as", "cfq", and "noop" are
# also legal values.  Comment this out to prevent ktune from changing I/O
# scheduler settings.
ELEVATOR="deadline"

# These are the devices, that should be tuned with the ELEVATOR
ELEVATOR_TUNE_DEVS="/sys/block/{sd,cciss,vd,dasd,xvd}*/queue/scheduler"

But it seems like CentOS 7 has left ktune behind. I see an alternate method to change the default I/O scheduler:

Add the elevator parameter to the GRUB_CMDLINE_LINUX line in the /etc/default/grub file.

# cat /etc/default/grub
...
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg00/lvroot rd.lvm.lv=vg00/lvswap elevator=noop"
...

And it goes on. But this would be a system-wide change. I'm looking for a solution like I had in CentOS 6 where I could specify which block devices would get the I/O scheduler specified by the ELEVATOR parameter. I was hoping I could just add the elevator_tune_devs parameter to the GRUB_CMDLINE_LINUX line, but according to this, there is no such kernel parameter. I know I can do this:

echo 'noop' > /sys/block/hda/queue/scheduler

for example, but I was hoping for something that lasts past the reboot. The best solution so far is to stick that echo command in a one-shot service so it'd be run every time at boot, but I was hoping for a cleaner method similar to the CentOS 6 solution.

Levi Uzodike
  • 125
  • 6
  • Put the commands in /etc/rc.d/rc.local, it'll last past the reboot. –  Nov 26 '19 at 23:21
  • Yeah, that's what I meant as a one-shot service (``systemd`` executes ``/etc/rc.d/rc.local`` as part of the service ``rc-local``), but I was looking for a cleaner method, like I said at the end. Thanks, though – Levi Uzodike Nov 26 '19 at 23:23
  • I guess we have very different ideas of what clean means. Adding another piece of software where it's unnecessary for something so simple as this would not be my choice. –  Nov 26 '19 at 23:26
  • Honestly, I'm a newb. I just got my perception of `rc.local` from the answers here: https://unix.stackexchange.com/questions/471824/what-is-the-correct-substitute-for-rc-local-in-systemd-instead-of-re-creating-rc – Levi Uzodike Nov 26 '19 at 23:42

1 Answers1

5

You have at least two methods:

  • use a custom tuned profile with the right disk option
  • insert the "echo noop" command in /etc/rc.local or create a specific systemd service.

EDIT: here you can find an example tuned.conf file:

# tuned configuration

[main]
summary=ZFS General non-specialized tuned profile
include=balanced

[disk]
# Comma separated list of devices, all devices if commented out.
type=disk
devices=sda,sdb
elevator=noop

As described in the RHEL tuned guide I linked above you have different possibilities to define the device list:

  • via coma separated list (as per example above);
  • via wildcards (eg: sd*);
  • to all disks, by not specifying anything (as by the comment included in the file above).
shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • hmm, Are you saying that putting ``[disk]`` ``devices=sd*, cciss*, vd*, dasd*, xvd*`` in ``/etc/tuned/my-profile/tuned.conf`` (for example) would make the ``elevator`` parameter in the ``GRUB_CMDLINE_LINUX`` line in ``/etc/default/grub`` only apply to the disks in ``devices``? – Levi Uzodike Nov 26 '19 at 23:39
  • To be clear, I'm asking for clarification on the first method you listed, please. I can't test it right now, but please provide and example of what to do if what I commented is not what you were suggesting. – Levi Uzodike Nov 27 '19 at 00:38
  • 1
    Yes you can optionally filter devices in the `[disk]` section of a tuned profile. But the `elevator` you set there is inserted into sysfs by tuned. grub isn't involved. – John Mahowald Nov 27 '19 at 00:49
  • 1
    @LeviUzodike I updated my answer with a practical example – shodanshok Nov 27 '19 at 10:19