fstrim ou discard no SSD?

março 18th, 2017 by rudsonalves Leave a reply »

Este post é apenas um pequeno update para a instalação de dispositivos SSD no GNU/Linux. Com o passar dos anos tive a oportunidade de evoluir mais minha compreensão destes dispositivos SSD no GNU/Linux, no entanto, uma vez instalado o sistema fica uma certa inércia para se questionar e mesmo se propor a fazer mudanças no que está funcionando. Como tenho mexido pouco no sistema nos últimos anos, algumas escolhas tomadas em meus textos tem se tornado obsoletas e necessitam de alguma atualização. A parte boa é que as alterações propostas aqui não fazem grandes mudanças no sistema, podendo serem realizadas sem traumas.

Recentemente instalei uma máquina com SSD + HD para um amigo e aproveitei para fazer uma pesquisa na rede para atualizar meus conceitos sobre estes dispositivos, e saber o que se tem feito com respeito a instalação destes no sistema.

A maioria das escolha apresentadas nos textos (inclusive nos meus Linux no Avell B155MAX e Inspiron com SSD e boot efi) não mudaram muito, mas pude olhar com mais atenção a alguns detalhes que não me ative a princípio.

Para otimizar a performance do SSD, sempre utilizei o “discard” no /etc/fstab. Primeiro por ser uma solução simples e segundo por acreditar que o kernel pudesse fazer este trabalho muito bem. Não duvido que o kernel Linux tenha evoluído o suficiente para isto e que em breve esta solução venha a ser a recomendada. No entanto, este procedimento faz com que o sistema envie uma operação do TRIM em real-time, ou seja, sempre que um arquivo é apagado/movido no SSD, gerando uma quantidade excessiva de trabalho para o dispositivo, tornando o acesso ao SSD mais lento.

Trocando em miúdos, diferentemente dos HDs, onde as trilhas podem ser sobrescritas a todo momento, nos SSDs os blocos de memória devem ser apagados antes de serem liberados para regravação. Quando se usa o “discard” no /etc/fstab, este processo é realizado a cada bloco liberado, gerando sobrecarga desnecessária ao SSD e consumindo sua performance. Já ao utilizar o comando fstrim semanalmente (ou diariamente) este processo será realizado em background, apenas uma vez, seja na semana ou no dia, e não a cada acesso de reescrita no SSD. Obviamente o período para a execução do fstrim depende muito do seu uso do SSD, mas na maioria dos casos a execução semanalmente parece ser suficiente.

Uma boa discussão sobre isto pode ser encontrada no artigo How to properly activate TRIM for your SSD on Linux: fstrim, lvm and dm-crypt. Embora o artigo seja de 2013, ainda está atual suas argumentações.

Botando a Mão na Massa

Para executar esta tarefa considere criar um script do_fstrim como o código abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/bash
 
LOGFILE=/var/log/ssd_trim.log
SSD_MOUNT='/ /home'
 
[ ! -e $LOGFILE ] && touch $LOGFILE
 
# -----------   Start script --------------|
echo "*** $(date -R) ***" | tee -a $LOGFILE
for MNT in $SSD_MOUNT; do
    fstrim -v $MNT | tee -a $LOGFILE
done
echo "    -------------------------------" | tee -a $LOGFILE

Este script foi escrito sobre a proposta do LQSlack. Altere o valor da variável SSD_MOUNT, na linha 4, para a lista de partições do SSD montadas em seu sistema, apenas separadas por um espaço.

Para terminar copie o script acima para o diretório /etc/cron.weekly/ ou /etc/cron.daily/, para executar o comando fstrim diariamente ou semanalmente, respectivamente. Eu o uso semanalmente.

root@luskan:# chmod +x do_fstrim
root@luskan:# cp do_fstrim /etc/cron.weekly/

Para testar apenas execute o do_fstrim

root@luskan:# /etc/cron.weekly/do_fstrim
*** Fri, 17 Mar 2017 18:37:09 -0300 ***
/: 13.1 GiB (14066356224 bytes) trimmed
/home: 84.5 GiB (90675343360 bytes) trimmed
    -------------------------------

O comando pode demorar um pouco, dependendo do uso do SSD, tenha paciência.

Para terminar, remova o “discard” das linhas de montagem das partições no /etc/fstab e as alterações estão prontas. Como disse, nada traumático.


QR Code
Advertisement

Deixe uma resposta

This blog is kept spam free by WP-SpamFree.