Setra persistent blockdev setra leggi avanti

14

Ho alcuni SSD montati su /dev/sda1e /dev/sdb1su un server SLES 11 SP2 e sono stato in grado di modificare l'impostazione di lettura in anticipo 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

Come posso mantenere questa impostazione all'avvio? In particolare, esiste un'impostazione corrispondente sysctl.confo dovrò accontentarmi di uno script rc per farlo accadere?

block-device ssd sles

— Banjer
fonte

2

Non so se esiste una soluzione "adeguata" a questo, ma le regole di udev sarebbero sicuramente più appropriate di uno script RC.

— Patrick,

3

Perché vorresti aumentare il read-ahead su un SSD BTW? Non riesco a capire il punto dato che gli SSD hanno tempi di ricerca ridotti.

— Stéphane Chazelas,

16

Suggerirei di usare udev per impostare i parametri per i dischi SSD. In questo modo è possibile configurare uno scheduler di coda specifico più appropriato per SSD, ecc. È inoltre possibile applicare parametri solo ad alcuni dispositivi, in base a molti parametri.

Puoi ottenere gli attributi specifici necessari per abbinare i tuoi dispositivi (es. Il modello del disco e il produttore) eseguendo:

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

e controllando tutte le coppie ATTR per il dispositivo a blocchi.

Un altro vantaggio è la possibilità di impostare i parametri per i dischi collegabili (ad es. In alloggiamenti o alloggiamenti per hotswap) e l'impostazione verrà applicata a tutti i nuovi dispositivi, a condizione che i parametri del dispositivo corrispondano.

Ecco un esempio per applicare uno scheduler specifico per SSD Intel, il valore di lettura desiderato (4096 blocchi = 2048 kb) e anche uno scheduler diverso per tutti gli altri 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"

Dopo aver salvato il file, puoi verificare se la tua regola corrisponderà al dispositivo e cosa farà udev usando udevadm:

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

Questo stampa tutte le regole che udev carica, cosa corrisponde, cosa no e quali decisioni prenderà udev quando il dispositivo viene collegato.

Spero che sia di aiuto.

— zorlem
fonte

Buone informazioni Proverò alcune regole udev simili quando avrò la possibilità e torno da te. Stiamo usando quelli OCZ vertex 3, ma non credo che le tue regole suggerite siano specifiche per Intel, ad eccezione del campo del modello, giusto?

— Banjer,

Sì, non c'è nulla di specifico per gli SSD Intel, l'ho usato come esempio per filtrare solo per attributi. Dovrai utilizzare udevadm infoper trovare i parametri specifici per il tuo hardware.

— zorlem,

10

Si noti che il read-ahead può essere impostato almeno tramite /sys ( /sys/class/block/sda/queue/read_ahead_kb) blockdeve hdparm( hdparm -a).

hdparmsu Debian e i suoi derivati viene fornito con uno hdparm.confche specifica gli attributi per dispositivo da impostare all'avvio e su hot plug (tramite udevregole).

Quindi puoi avere:

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

(meglio usare gli ID di quelli sdache possono cambiare da un avvio all'altro).

— Stéphane Chazelas
fonte

Vedo hdparmsu SLES 11, ma non riesco a individuare hdparm.conf. Google sembra dirmi che è necessario uno script rc per hdparmfar sì che qualsiasi impostazione persista, almeno su SuSE.

— Banjer,

@Banjer, sì, sembra che sia un'estensione Debian (leggermente modificata in Ubuntu): uno script shell eseguito all'avvio anticipato e hot plug del dispositivo che analizza quel file e chiama di hdparmconseguenza. Ho aggiornato la risposta.

— Stéphane Chazelas,

+1 per specificare il /syspercorso sebbene la udevregola di @zorlem sia piuttosto utile per la configurazione di avvio.

— Totor,

-1

Non c'è nulla di corrispondente in sysctl, quindi sì, /etc/rc.localè un modo o simile. E attenzione, - l'ho notato personalmente su Ubuntu - quei cambiamenti si spostano ulteriormente anche dopo essere stati impostati una volta dopo l'avvio, quindi potrebbe anche avere senso usarlo crontabper mantenerlo.

— poige
fonte