Paramètre de lecture anticipée de BlockDev Setra persistant

14

J'ai des SSD montés sur /dev/sda1et /dev/sdb1sur un serveur SLES 11 SP2, et j'ai pu modifier le paramètre de lecture anticipée avec 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

Comment conserver ce paramètre au démarrage? Plus précisément, y a-t-il un paramètre correspondant sysctl.confou devrais-je me contenter d'un script rc pour que cela se produise?

block-device ssd sles

— Banjer
source

2

Je ne sais pas s'il existe une solution «appropriée» à cela, mais les règles udev seraient certainement plus appropriées qu'un script RC.

— Patrick

3

Pourquoi voudriez-vous augmenter la lecture anticipée sur un SSD BTW? Je ne vois pas l'intérêt étant donné que les SSD ont de petits temps de recherche.

— Stéphane Chazelas

16

Je vous suggère d'utiliser udev pour définir les paramètres des disques SSD. De cette façon, vous pouvez configurer un planificateur de file d'attente spécifique qui est plus approprié pour le SSD, etc. Vous pouvez également appliquer des paramètres uniquement à certains périphériques, en fonction d'un grand nombre de paramètres.

Vous pouvez obtenir les attributs spécifiques nécessaires pour correspondre à vos périphériques (par exemple, le modèle de disque et le fabricant) en exécutant:

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

et vérifier toutes les paires ATTR pour votre périphérique bloc.

Un autre avantage est la possibilité de définir les paramètres des disques enfichables (par exemple, dans des boîtiers ou des baies de Hotswap) et le réglage sera appliqué à tous les nouveaux périphériques, à condition que les paramètres du périphérique correspondent.

Voici un exemple pour appliquer un planificateur spécifique pour les SSD Intel, la valeur de lecture anticipée souhaitée (4096 blocs = 2048 ko), et également appliquer un planificateur différent pour tous les autres 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"

Après avoir enregistré le fichier, vous pouvez tester si votre règle correspondra à l'appareil et ce que fera udev en utilisant udevadm:

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

Cela affiche toutes les règles que udev charge, ce qui correspond, ce qui ne fonctionne pas et quelles décisions udev prendra lorsque le périphérique est branché.

J'espère que cela t'aides.

— zorlem
source

Bonne info. Je vais essayer des règles udev similaires quand j'en aurai l'occasion et que je reviendrai vers vous. Nous utilisons OCZ vertex 3des, mais je ne pense pas que vos règles suggérées soient spécifiques à Intel, à l'exception du champ du modèle, n'est-ce pas?

— Banjer

Oui, il n'y a rien de spécifique aux SSD Intel, je l'ai utilisé comme exemple de filtrage par attributs uniquement. Vous devrez utiliser udevadm infopour trouver les paramètres spécifiques à votre matériel.

— zorlem

10

Notez que la lecture anticipée peut être définie au moins via /sys( /sys/class/block/sda/queue/read_ahead_kb) blockdevet hdparm( hdparm -a).

hdparmsur Debian et ses dérivés est livré avec un hdparm.confqui spécifie les attributs par périphérique à définir au démarrage et lors du branchement à chaud (via des udevrègles).

Vous pouvez donc avoir:

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

(mieux vaut utiliser des identifiants que ceux sdaqui peuvent changer d'un démarrage à l'autre).

— Stéphane Chazelas
source

Je vois hdparmsur SLES 11, mais ne semble pas localiser hdparm.conf. Google semble me dire qu'un script rc est nécessaire pour que tous les hdparmparamètres persistent, au moins sur SuSE.

— Banjer

@Banjer, oui, il semble que ce soit une extension Debian (légèrement modifiée dans Ubuntu): un script shell exécuté au démarrage précoce et une connexion à chaud de périphérique qui analyse ce fichier et appelle en hdparmconséquence. J'ai mis à jour la réponse.

— Stéphane Chazelas

+1 pour spécifier le /syschemin, bien que la udevrègle @zorlem soit plutôt agréable pour la configuration de démarrage.

— Totor

-1

Il n'y a rien qui corresponde sysctl, alors oui, /etc/rc.localc'est un moyen, ou similaire. Et méfiez-vous, - j'ai personnellement remarqué que sur Ubuntu, - ces changements dérivent encore plus, même en étant définis une fois après le démarrage, donc, il pourrait même être judicieux crontabde les conserver.

— poige
source