Configuración persistente de lectura anticipada de bloquedev setra

14

Tengo algunas unidades SSD montados sobre /dev/sda1y /dev/sdb1en el servidor SLES 11 SP2, y yo era capaz de ajustar la configuración de la lectura anticipada con 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

¿Cómo persisto esta configuración en el arranque? Específicamente, ¿hay una configuración correspondiente sysctl.confo tendré que conformarme con un script rc para que esto suceda?

block-device ssd sles Banjer
fuente
2
No sé si hay una solución 'adecuada' para esto, pero las reglas de udev ciertamente serían más apropiadas que un script RC.
Patrick
3
¿Por qué querría aumentar la lectura anticipada en un SSD BTW? No puedo ver el punto dado que los SSD tienen tiempos de búsqueda pequeños.
Stéphane Chazelas

Respuestas:

16

Te sugiero que uses udev para establecer parámetros para los discos SSD. De esta forma, puede configurar un planificador de colas específico que sea más apropiado para SSD, etc. También puede aplicar parámetros solo a algunos de los dispositivos, en función de muchos parámetros.

Puede obtener los atributos específicos necesarios para que coincidan con sus dispositivos (por ejemplo, el modelo de disco y el fabricante) ejecutando:

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

y verificando todos los pares ATTR para su dispositivo de bloque.

Otro beneficio es la capacidad de establecer los parámetros para los discos conectables (por ejemplo, en recintos o bahías de intercambio dinámico) y la configuración se aplicará a todos los dispositivos nuevos, siempre que los parámetros del dispositivo coincidan.

Aquí hay un ejemplo para aplicar un planificador específico para SSD Intel, su valor de lectura deseado (4096 bloques = 2048 kb), y también aplicar un planificador diferente para todos los demás 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"

Después de guardar el archivo, puede probar si su regla coincidirá con el dispositivo y qué hará udev usando udevadm:

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

Esto imprime todas las reglas que carga udev, qué coincide, qué no y qué decisiones tomará udev cuando se conecte el dispositivo.

Espero que esto ayude.

zorlem
fuente
Buena informacion Voy a probar algunas reglas de udev similares cuando tenga la oportunidad y vuelva a contactarlo. Estamos usando OCZ vertex 3's, pero no creo que sus reglas sugeridas sean específicas de Intel, excepto por el campo del modelo, ¿correcto?
Banjer
Sí, no hay nada específico para los SSD de Intel, lo usé como un ejemplo para filtrar solo por atributos. Necesitará usar udevadm infopara encontrar los parámetros específicos de su hardware.
zorlem
10

Tenga en cuenta que la lectura anticipada se puede configurar al menos mediante /sys( /sys/class/block/sda/queue/read_ahead_kb) blockdevy hdparm( hdparm -a).

hdparmen Debian y sus derivados viene con un hdparm.confatributo que especifica los atributos por dispositivo que se establecerán en el arranque y en el hot-plug (mediante udevreglas).

Entonces puedes tener:

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

(es mejor usar ID que las sdaque pueden cambiar de un arranque a otro).

Stéphane Chazelas
fuente
Veo hdparmen SLES 11, pero parece que no puedo localizar hdparm.conf. Google parece decirme que se necesita un script rc para que cualquier hdparmconfiguración persista, al menos en SuSE.
Banjer
@Banjer, sí, parece que es una extensión de Debian (ligeramente modificada en Ubuntu): un script de shell que se ejecuta en el arranque temprano y el dispositivo de conexión en marcha que analiza ese archivo y llama en hdparmconsecuencia. He actualizado la respuesta.
Stéphane Chazelas
+1 para especificar la /sysruta, aunque la udevregla @zorlem es bastante buena para la configuración de arranque.
Totor
-1

No hay nada que corresponda sysctl, así que sí, /etc/rc.locales una forma o similar. Y tenga cuidado, personalmente noté que en Ubuntu, esos cambios se desvían aún más, incluso se establecen una vez después del arranque, por lo que incluso podría tener sentido usarlos crontabpara mantenerlos.

poige
fuente