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
sudo blockdev --getra /dev/sdb

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?

  • 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 5, 2013 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. Apr 5, 2013 at 19:18

3 Answers 3


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.

  • 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, 2013 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, 2013 at 16:58

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).

  • 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, 2013 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. Apr 11, 2013 at 13:22
  • +1 for specifying the /sys path although @zorlem udev rule is pretty nice for bootup configuration.
    – Totor
    Jan 26, 2014 at 15:48
  • It should be /sys/block, not /sys/class/block, at least in Linux 4.14 and higher
    – Ruslan
    Dec 2, 2021 at 9:15

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.