16

I've got some SSDs mounted up on /dev/sda1 and /dev/sdb1 on a SLES 11 SP2 server, and I was able to tweak the read ahead setting with blockdev --setra:

sudo blockdev --setra 4096 /dev/sda
sudo blockdev --setra 4096 /dev/sdb
sudo blockdev --getra /dev/sda
4096
sudo blockdev --getra /dev/sdb
4096

How do I persist this setting on boot? Specifically, is there a corresponding setting in sysctl.conf, or will I have to settle for an rc script to make this happen?

Anthon
  • 79,293
Banjer
  • 2,920
  • 2
    I don't know if there is a 'proper' solution to this, but udev rules would certainly be more proper than an RC script. – phemmer Apr 05 '13 at 18:23
  • 3
    Why would you want to increase the read-ahead on an SSD BTW? I can't see the point given that SSDs have small seek times. – Stéphane Chazelas Apr 05 '13 at 19:18

3 Answers3

17

I would suggest you use udev to set parameters for the SSD disks. This way you can configure a specific queue scheduler that is more appropriate for SSD, etc. You can also apply parameters only to some of the devices, based on a lot of parameters.

You can obtain the specific attributes necessary to match your devices (eg. the disk model and manufacturer) by executing:

udevadm info -a -p /sys/block/sda

and checking all ATTR pairs for your block device.

Another benefit is the ability to set the parameters for pluggable disks (eg. in enclosures or hotswap bays) and the setting will be applied to all new devices, provided that the device parameters match.

Here is an example to apply a specific scheduler for Intel SSDs, your desired readahead value (4096 blocks = 2048 kb), and also apply a different scheduler for all other SSD:

cat /etc/udev/rules.d/99-ssd.rules
# http://unix.stackexchange.com/a/71409/36574
# Setting specific kernel parameters for a subset of block devices (Intel SSDs)
SUBSYSTEM=="block", ATTRS{model}=="Intel SSDSC*", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{bdi/read_ahead_kb}="2048", ATTR{queue/scheduler}="deadline"
# for all other non-rotational block devices set a scheduler to 'noop' and readahead to 1024KB
SUBSYSTEM=="block", ATTR{queue/rotational}=="0", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{bdi/read_ahead_kb}="1024", ATTR{queue/scheduler}="noop"

After saving the file you can test if your rule will match the device and what will udev do using udevadm:

udevadm test --action=add /sys/block/sda

This prints all the rules that udev loads, what matches, what doesn't, and what decisions will udev make when the device is plugged in.

Hope this helps.

zorlem
  • 625
  • Good info. I'm going to try some similar udev rules out when I get a chance and get back to you. We are using OCZ vertex 3's, but I don't think your suggested rules are specific to Intel, except for the model field, correct? – Banjer Apr 11 '13 at 11:29
  • Yes, there is nothing specific to intel SSDs, I used it as an example for filtering by attributes only. You will need to use udevadm info to find the parameters specific to your hardware. – zorlem Apr 11 '13 at 16:58
13

Note that read-ahead can be set at least via /sys (/sys/class/block/sda/queue/read_ahead_kb), blockdev and hdparm (hdparm -a).

hdparm on Debian and its derivatives comes with an hdparm.conf that specify per-device attributes to be set on boot, and upon hot-plug (via udev rules).

So you can have:

/dev/disk/by-id/my-disk... {
  read_ahead_sect = 4096
}

(better to use IDs than sda which can change from one boot to the next).

Stéphane Chazelas
  • 544,893
  • I see hdparm on SLES 11, but can't seem to locate hdparm.conf. Google seems to tell me an rc script is needed for any hdparm settings to persist, at least on SuSE. – Banjer Apr 11 '13 at 11:29
  • @Banjer, yes, it looks like that's a Debian extension (slightly modified in Ubuntu): a shell script run upon early boot and device hot plug that parses that file and calls hdparm accordingly. I've updated the answer. – Stéphane Chazelas Apr 11 '13 at 13:22
  • +1 for specifying the /sys path although @zorlem udev rule is pretty nice for bootup configuration. – Totor Jan 26 '14 at 15:48
  • It should be /sys/block, not /sys/class/block, at least in Linux 4.14 and higher – Ruslan Dec 02 '21 at 09:15
-1

There's nothing corresponding in sysctl, so, yep, /etc/rc.local is a way, or alike. And beware, — I personally noticed that on Ubuntu, — those changes drift further even being set once after boot, so, it might even has sense to use crontab to keep it.

poige
  • 6,231