Configuração de leitura antecipada do blockdev setraev


14

Eu tenho alguns SSDs montado em cima /dev/sda1e /dev/sdb1em um servidor SLES 11 SP2, e eu era capaz de ajustar a ler adiante ajuste com 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

Como persisto essa configuração na inicialização? Especificamente, existe uma configuração correspondente sysctl.confou terei de me contentar com um script rc para que isso aconteça?


2
Não sei se existe uma solução 'adequada' para isso, mas as regras do udev certamente seriam mais adequadas do que um script RC.
Patrick

3
Por que você deseja aumentar a leitura antecipada em um SSD BTW? Não vejo o ponto, já que os SSDs têm tempos de busca pequenos.
Stéphane Chazelas

Respostas:


16

Eu sugiro que você use o udev para definir parâmetros para os discos SSD. Dessa forma, você pode configurar um agendador de filas específico que seja mais apropriado para SSD, etc. Você também pode aplicar parâmetros apenas a alguns dos dispositivos, com base em muitos parâmetros.

Você pode obter os atributos específicos necessários para corresponder aos seus dispositivos (por exemplo, modelo e fabricante do disco) executando:

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

e verificando todos os pares ATTR para o seu dispositivo de bloco.

Outro benefício é a capacidade de definir os parâmetros para discos conectáveis ​​(por exemplo, em gabinetes ou baias de hotswap) e a configuração será aplicada a todos os novos dispositivos, desde que os parâmetros do dispositivo correspondam.

Aqui está um exemplo para aplicar um agendador específico para SSDs Intel, o valor desejado de leitura (4096 blocos = 2048 kb) e também aplicar um agendador diferente para todos os outros SSDs:

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"

Após salvar o arquivo, você pode testar se sua regra corresponderá ao dispositivo e o que o udev fará usando o udevadm:

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

Isso imprime todas as regras que o udev carrega, o que corresponde, o que não corresponde e quais decisões o udev tomará quando o dispositivo estiver conectado.

Espero que isto ajude.


Boa informação. Vou experimentar algumas regras semelhantes do udev quando tiver uma chance e voltar para você. Estamos usando OCZ vertex 3's, mas não acho que suas regras sugeridas sejam específicas da Intel, exceto no campo do modelo, correto?
Banjer

Sim, não há nada específico para os SSDs da Intel, usei-o como exemplo para filtrar apenas por atributos. Você precisará usar udevadm infopara encontrar os parâmetros específicos para o seu hardware.
Zorlem 11/04

10

Observe que a leitura antecipada pode ser definida pelo menos via /sys( /sys/class/block/sda/queue/read_ahead_kb) blockdeve hdparm( hdparm -a).

hdparmO Debian e seus derivados vêm com um hdparm.confque especifica os atributos por dispositivo a serem configurados na inicialização e no hot-plug (via udevregras).

Então você pode ter:

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

(é melhor usar IDs do sdaque mudar de uma inicialização para a seguinte).


Eu vejo hdparmno SLES 11, mas não consigo localizar hdparm.conf. O Google parece me dizer que é necessário um script rc para que as hdparmconfigurações persistam, pelo menos no SuSE.
Banjer

@Banjer, sim, parece que é uma extensão do Debian (ligeiramente modificada no Ubuntu): um shell script executado na inicialização antecipada e no hot plug do dispositivo que analisa esse arquivo e chama de hdparmacordo. Eu atualizei a resposta.
Stéphane Chazelas

+1 para especificar o /syscaminho, embora a udevregra @zorlem seja bastante agradável para a configuração de inicialização.
Totor 26/01

-1

Não há nada correspondente sysctl, portanto, sim, /etc/rc.localé um caminho ou algo parecido. E cuidado - notei pessoalmente que no Ubuntu - essas mudanças ainda são definidas uma vez após a inicialização, portanto, pode até fazer sentido usá crontab-lo para mantê-lo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.