Como configurar SSDs no Linux para maior desempenho

Excelente tutorial, espero ver mais coisa bacana de Linux por aqui.

Excelente tutorial, espero ver mais coisa bacana de Linux por aqui.

Era exatamente isso que eu iria dizer. Se eu num fosse fanatico em games eu tinha instalado aqui o Ubuntu.

No comando do artigo as vezes a distância entre uma palavra e outra é de vários espaços. Como fazer igual sem ctrl+c ctrl+v?

Excelente tutorial, simples e direto, muito bom pra quem não tem conhecimento técnico e utiliza o sistema pelas inúmeras vantagens em relação ao Windows. Também gostaria de ver mais conteúdo sobre Linux e Software Livre no site!

Artigo interessante, cabe algumas observações:

1. Não vejo tanta necessidade assim em alterar os parâmetros padrão sobre a questão do acesso, adicionando noatime e o no diartime. Eu acho que o parâmetro padrão do kernel (que é o relatime) é uma opção mais segura, evitando problemas com alguns programas, principalmente com indexadores.

http://lwn.net/Articles/244829/

2. Sobre o deadline, é mais elegante colocá-lo nas opções do gerenciador de boot, colocando elevator=deadline na linha de opções do kernel, ao invés de usar o rc.local para esse fim.

3. O uso do parâmetro discard (ou seja, TRIM em tempo real) nem sempre tem funcionado muito bem no Linux, demonstrando casos aleatórios de comprometimento na performance, principalmente com SSDs de controlador SandForce. Uma alternativa para isso é usar o fstrim manualmente (fstrim -v ponto_de_montagem). Para facilitar a coisa, você pode colocar o fstrim para ser executado via cron.

Eu fiz algumas coisas a mais, não sei se realmente produzem diferença no desempenho. Mas pela dor de cabeça que me deu, acho que vale a pena compartilhar, para que outros não percam tempo à toa.

Uso o Fedora 20 e mais ou menos o passo a passo que fiz foi:

- Primeiro passo (antes de formatar a unidade), verificar se a opção AHCI do BIOS está habilitada [1]. É importante para que opção TRIM funcione.

- Segundo, sobre o journaling do Ext4 [2]. Você pode:

• Habilitar o modo writeback do journaling. Assim, o journaling pode ser gravado antes do dado real ser gravado (gravação fora de ordem). O problema da opção é que numa derrubada abrupta do sistema alguns arquivo podem aparecer com valores antigos [3].
  • tune2fs -o journal_data_writeback /dev/sda1
• Ou desabilitar completamente journaling.
  • tune2fs -O ^has_journal /dev/sda1
• Eu escolhi desabilitar o journaling. No fundo eu fiz os dois, mas foi mais por preguiça de estudo do que isso ser uma necessidade.

- Terceiro, fstab, além do que o Gabriel disse, você terá de adiconar mais algumas coisas (mais informações em [3]):

• discard,noatime,data=writeback,commit=60
• Eu li em algum lugar (sinto muito pela falta de referência, mas nada que uma googlada não ache) que nodiartime está contido na opção noatime, então se você opta por noatime, não precisa especificar nodiartime.
• A opção data=writeback só vai funcionar se você tiver a habilitado com o tune2fs, caso contrário o disco não vai montar. O commit é o tempo para sincronizar dados e metadados (isto é, deixar o journaling em dia) a cada X segundos. No caso acima é a cada X = 60 segundos.
• Novamente, eu digo que eu acredito que essas opções não fazem sentido se o journaling estiver desligado, mas isso carece de maior investigação. Eu acabei deixando assim.

-  Quarto, grub.

• Além da alteração que o ignacho disse, para modificar o io scheduler do linux [6], encontrei em vários tópicos dizendo que a adição de libata.force=noncq diminui a instabilidade do SSD [4].

- Quinto, swap.

• Convém deixar o swap em um disco que não seja o SSD caso você possa fazer isso (em caso de notebook é difícil).
• Adicionando no arquivo /etc/sysctl.conf a linha vm.swappiness=1, você faz com que o sistema operacional evite ao máximo usar o swap. Caso você tenha bastante memória pode até desabilitar vm.swappinees=0. [5]

- Sexto, /var/spool, /var/log, /tmp....

• O diretórios /tmp, /var/spool, /var/log, /var/tmp, recebem bastante escrita. Há duas opções, mountar esse diretório em partições separadas (eu particularmente, monto /tmp e /var inteiramente em partições separadas) ou montá-los na memória usando fstab, por exemplo, tmpfs /var/spool tmpfs defaults,noatime 0 0.
• O problema de montar os diretórios na memória é que você, por exemplo, ficará sem log.

- Sétimo, caching de browsers.

• Você pode remover o caching dos browsers ou montar os diretórios usados para o caching na memória, ou em outra partição. Depende da sua possibilidade. Como o meu /home é montada em um disco comum, eu não tive freezing com browsers.

Um adendo é se você estiver usando a útlima versão do kde (a minha atual é a 4.13.3). Acho que você vai ficar muito feliz se desabilitar o indexador dele: sudo balooctl stop && sudo balooctl disable. Eu reformatei todo o computador só por conta dele, para só então descobrir que era ele quem causava freezing no linux. O que me ajudou a descobrir isso foi o iotop.

Um último detalhe do Fedora 20. Um mv /var/log/journaling para /var/log/journaling.old, pode deixar sua inicialização bem mais rápido. Porém, já digo que não sei os efeitos práticos disso: vulgo, fiz e até agpra não deu problema.

Se alguém achar algumas opções muito radicais, a minha decisão particular foi maximar operações de leitura na unidade SSD e minimar escrita, tentando redirecioná-las ao máximo para discos comuns. Por dois motivos: escritas não são tão rápidas em SSDs, principalmente os mais baratinhos que gravam mais de um bit por célula/transistor. Além disso, a escrita desgasta a célula e, novamente, as unidades SSDs baratinhas que gravam mais de um bit por célula acabam se desgastando mais [7].

Enfim, com essas configurações eu tenho tido bons resultados, até agora bem satisfatórios.


[1] https://wiki.freeswitch.org/wiki/SSD_Tuning_for_Linux
[2] http://askubuntu.com/questions/76913/how-can-i-check-if-a-particular-partition-ext4-is-journaled
[3] http://linux.die.net/man/8/mount
[4] http://lukewickstead.wordpress.com/2013/02/10/ssd-instability-under-linux/
[5] http://en.wikipedia.org/wiki/Swappiness
[6] https://www.ibm.com/developerworks/community/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/ssd_no_desktop_linux_parte_2?lang=en
[7] http://www.eetimes.com/document.asp?doc_id=1279762
 

Segue algumas dicas interessantes para linux (em inglês):

https://sites.google.com/site/easylinuxtipsproject/ssd

OBS.: com relação ao TRIM a versão mais recente do ubuntu já vem com ele ativado por padrão para SSD's da Intel e da Samsung.

O Deadline vem como padrão no Ubuntu.

Como uso HD (um Hitachi IDE de 2007) o mais interessante para mim é o CFQ, que em vez de dar prioridade a leitura ou escrita, tenta dar atenção as duas requisições ao mesmo tempo. É do tipo que mesmo que o HD esteja ocupado com várias tarefas, não te deixa na mão quando precisar iniciar mais uma nova. Quando faço uma nova instalação do Ubuntu (ou outra distribuição), é uma das primeiras coisas que faço é mudar para CFQ. E pelos testes que fiz aqui, o CFQ junto com o sistema de arquivos Btrfs funciona lindamente com os tradicionais HDs.

Há quem diga que os SSDs funcionam bem com o Noop, já que este funciona de uma maneira simples: dá prioridade para aquela operação que chegar primeiro (seja leitura ou escrita), enquanto a seguinte espera a sua vez na fila.

Bom que o Windows já faz tudo isso automaticamente.

Bom que o Windows já faz tudo isso automaticamente.

Mas nem todos preferem Windows! EU, particularmente só uso por conta da compatibilidade com Games, rodo muitos jogos na máquia aqui em casa! 

Mas se a biblioteca de programas, games e aplicativos fossem iguais, eu iria sem duvida de Linux!