Pular para o conteúdo principal

SSD no linux

Mitos e verdades do SSD no Linux - Instalando, configurando e otimizando SSD no Linux


SSD são suportados no Linux desde o kernel 2.6.29.
Schedulers e File Systems também suportam os 'discos sólidos' ou 'não-rotacionais' (SSDs) há um bom tempo.
A maioria dos artigos que existem na internet são bem antigos e não refletem os ambientes atuais dos sistemas Linux.
Este artigo trás alguns macetes para otimizar o SSD num ambiente onde o sistema operacional estará instalado nele.
Tiro alguns mitos de que seria necessário mudanças bruscas no sistema para que o SSD seja bem aproveitado (hoje, basicamente no uso do dia-a-dia, nada é preciso após instala-lo) apenas alguns pontos a serem observados.

Eles são identificados automaticamente e funcionam perfeitamente sem nenhum problema caso seu S.O. esteja em bom estado e atualizado (bem como os demais hardwares do computador).
Ao rodar o seguinte comando, o retorno '1' é para HD e 0 para SSD.
cat /sys/block/sda/queue/rotational
(neste caso, estou verificando o dispositivo 'sda').

Havia um antigo receio de que o GNU/Linux poderia diminuir a vida útil dos SSDs, visto algums percalços no desenvolvimento e implantação do  suporte a eles nos diferentes programas que estão ao entorno do kernel e o próprio kernel em sí.
Vale lembrar que o Linux já foi acusado de estar destruindo os HDs (sobrecarregando-os) há 10 anos atrás, num problema que apareceu nos fóruns do ubuntu 7 e que acabou com os fabricantes de disco assumindo a culpa, porém a imagem errada pegou no Linux e ficou (https://www.theregister.co.uk/2007/11/01/ubuntu_laptop_disk_issues/)




MBR ou GPT

Ao criar a tabela de partição para formatar o SSD (e posteriormente inserir o sistema de arquivos, S.O. , etc...) o formato deve ser o GPT, ao invés do antigo, bom e velho (mais bom do que velho) MBR.


Porém, ao instalar a maioria das distros GNU/Linux, em mais de 95% delas, irá detectar o SSD e habilitar em GPT durante a instalação. Exceto se você forçar em outro formato.


Ou seja, neste quesito: Se você estiver usando uma distro atualizada e conhecida (ou derivada de uma das 4 grandes), não precisará fazer nada.


Escolha do File System: Btrfs vs Ext4 vs F2FS vs JFS vs Outros...

O filesystem deve possuir suporte ao TRIM, no kernel ele está presente desde o 2.6.
Os seguintes FS possui suporte ao TRIM: Ext4, Btrfs, JFS, XFS e F2FS.

Nos testes de performance com o kernel 4.0 o FS com melhor desempenho foi o F2FS, porém ele ainda é experimental e não está nos repositórios de algumas distribuições linux. Em ordem de desempenho, posteriormente vem o Btrfs e o Ext4, em alguns testes o XFS mostrou desempenho melhor que os outros, porém no geral considero-o em 4º atrás do Ext4.

Neste momento, visto o desenvolvimento destes 4 file systems e dependendo da distribuição que escolher opte primeiramente pelo Btrfs ou Ext4.
Ou seja, Debian, Ubuntu e derivados, continue no padrão do Ext4 Já com RHEL, Fedora e derivados, mantenha no padrão Brtfs.
Se quiser se aventurar no JFS, XFS e F2FS manda brasa, mas não terá melhoria alguma (pior, perderá!)

Ou seja, neste quesito: mantenha no padrão (ou no que já conheça).

Suporte ao TRIM

O recurso TRIM limpa os blocos do SSD que não são mais usados pelo sistema de arquivos. Isso irá otimizar o desempenho de gravação a longo prazo e é recomendado em SSD devido ao seu design. Isso significa que o sistema de arquivos é capaz de dizer ao SSD sobre esses blocos.

A opção 'discard' ao montar um ext4 emitirá tais comandos TRIM quando os blocos do sistema de arquivos forem liberados (chama-se descarte online).
No entanto, esse comportamento implica um pouco sobrecarga de desempenho. Desde o Linux 2.6.37, você pode evitar o uso da opção 'discard' e fazer isto ocasionalmente com o FITRIM (por exemplo, a partir de um agendamento no crontab).
O utilitário fstrim também faz isso (on-line), bem como a opção '-E discard' do fsck.ext4.

Já com o Btrfs existe a opção na montagem de passar o parâmetro 'ssd'

Tanto para o Btrfs e Ext4 passe as opções 'noatime', 'notail' e 'nodiratime'.
O 'noatime'  faz com que o sistema não atualize as propriedades dos arquivos quando eles são acessados, apenas quando são alterados, o que melhora bastante o desempenho. 
O 'nodiratime' desativa o registro de data e hora para diretórios (colocando o nodiratime já implica no noatime).
O 'notail' desabilita uma opção na qual o Filesystem usa o espaço sem uso de um bloco para armazenar o excesso de dados de outros blocos, ganhando assim mais espaço de armazenamento, porém cobrando a conta no quesito desempenho, desabilitando-o pode ser uma boa, porém não há ganhos significativos.

Estas duas opções também são aconselháveis para aumentar o desempenho em discos HD comuns e na qual você não necessita destas informações de data/hora dos acessos.

relatime X noatime/nodiratime

O noatime e o nodiratime desativam o 'atime', porém alguns aplicativos fazem uso dos dados atime, desligar este recurso pode gerar problemas pois alguns aplicativos contam com os dados do atime e falharão caso não esteja disponível.

O kernel usado no Red Hat Enterprise Linux 6 suporta outra alternativa, relatime. Relatime mantém dados do atime , mas não para cada vez que um arquivo é acessado. Com esta opção habilitada, os dados do atime são gravados no disco somente se um arquivo foi modificado desde que os dados do atime tenham sido atualizados (mtime), ou se o arquivo foi acessado pela última vez mais de um certo período de tempo atrás (por padrão, um dia).
Por padrão, todos os sistemas de arquivos são montados agora com o relatime habilitado. Para omitir este recurso em todo o sistema, use o parâmetro de inicialização default_relatime=0. Se relatime estiver ativado em um sistema por padrão, você pode omití-lo de qualquer sistema de arquivo específico montando aquele sistema de arquivo com a opção norelatime. Finalmente, para variar o período de tempo padrão antes do qual o sistema irá atualizar dados do atime de arquivo, use o parâmetro de inicialização relatime_interval= especificando o período em segundos. O valor padrão é 86400.
Ou seja, num sistema bas
eado no RHEL, ao invés de desativar o atime (com o nodiratime), instalar o fstrim e criar uma tarefa no CRONTAB para realizar ação, você simplesmente usa o relatime e insere um valor de tempo maior.

Porém, ao instalar a maioria das distros GNU/Linux, em mais de 95% delas, as opções 'discard' e 'noatime' já estarão ativas pois o instalador sabe que está sendo usado um disco SSD.

Ou seja, neste quesito: Novamente, se você estiver usando uma distro atualizada e conhecida (ou derivada de uma das 4 grandes), não precisará fazer nada.

Schedulers: CFQ vs Deadline vs Noop

O CFQ (Completely Fair Queuing) é o scheduler padrão de I/O do Linux desde o kernel 2.6.18 ele é quem coloca as solicitações síncronas enviadas por processos em filas numeradas e aloca o tempo para que cada uma destas filas acessem o disco, controlando entre outras coisas, a prioridade do acesso ao disco e a largura de banda para I/O.

A partir do Kernel 3.1 foi introduzido algumas opções de otimização no CFQ para SSDs e outros drives 'não-rotacionais' ('discos' que não são discos, como memórias flash, etc...) onde ele detecta este tipo de dispositivo e suporta múltiplos requests por vez e uma profundidade maior da fila. Seu funcionamento padrão em discos comuns é organizar as filas de acordo com setor e proximidade (lembrando que é um disco girando, sendo lido e gravado).

Existe outros schedulers no Linux, como o Deadline e o Noop. Para SSD o CFQ se mostra com o melhor desempenho, sendo este o padrão da maioria das distribuições.
Há na internet diversos artigos onde mostram como alterar o sistema para que use o Deadline em discos não-rotacionais (SSDs), porém não encontrei nenhum argumento que justifique isto.

Neste link, há uma comparação dos 3 schedulers no kernel 3.4 usando disco convencional (HDD) e SSD: http://www.phoronix.com/scan.php?page=article&item=linux_iosched_2012&num=1

Um dos argumentos é a opção fifo_batch do Deadline que controla o numero de pedido por lotes de solicitações de I/O no disco, com isto ele equilibra as taxas de latência vs transferência, focando a latência (pois o disco está girando e leva em consideração a proximidade do setor), porém ao inverter (já que no SSD não tem disco) você prioriza a taxa de transferência, em tese, melhorando o desempenho. Porém, mesmo assim, em benchmarks que verifiquei, o CFQ continua melhor e o ganho de transferência no Deadline com esta ação não produz uma melhoria visível.

Ou seja: Neste quesito, não faça nada.

Journaling

O Journaling cobra um pouco no desempenho, mas isto é um recurso muito importante para a recuperação dos dados em possíveis crashs no sistema.
Aí depende muito de cada um em desativa-lo, eu acho desnecessário (depende muito de qual uso terá este GNU/Linux com SSD).
Se em seu ambiente você terá um disco HD junto com SSD no Linux, você pode configurar para que o sistema use outro device ou partição para o Journal, apontando para uma área do HD (no mkfs.ext4 ao criar a partição do sistema que será instalado no SSD, use a opção '-J' para as configurações do journal, entre elas há um "device=" onde você aponta um outro dispositivo ou partição para usar como Journal, apontando assim, para o HD comum).

Caso mude o journal no ext4, habilite na montagem do SSD, além dos parametros já passados, os seguintes:
"journal_checksum" e o "journal_async_commit"

Neste queisto é opcional. Muitos o fazem, porém o ganho de vida útil com os atuais SSDs não será perceptível.


Updates

Kernel: O mais atual possível!
No benchmark de qual melhor File System, foi testado também os kernels 3.19 e 4.0, a melhoria no desempenho é gritante. Mantenha seu linux atualizado via repositório, não necessariamente você deva ser radical para usar versões unstable e/ou ficar compilando o que foi liberado horas antes (o perigo costuma morar aqui também).

Firmware do SSD

Mantenha atualizado também o firmware do seu SSD, geralmente cada fabricante distribui arquivos .ISO para atualizar o seu firmware, porém a forma de fazer este update muda em cada fabricante.

Não vou me estender sobre o benchmark, o link do excelente artigo na Phoronix (do Michale Larabel) é http://www.phoronix.com/scan.php?page=article&item=linux-40-ssd&num=1


Memoria SWAP

Não crie uma partição para memória SWAP na instalação do sistema.
Você pode não ter SWAP no seu SSD ou criar um SWAP como arquivo e otimizar a configuração do sysctl.conf para que apenas use a SWAP quando a RAM estiver em 95% ocupada ou mais.
No artigo abaixo, crie arquivo para usar como memória SWAP e não ter que criar uma partição para isto: http://www.esli-nux.com/2014/08/usar-arquivo-como-memoria-swap.html

Neste arquivo a seguir, você configura o uso do swap, colocando o swappiness em 0, você desativa, neste artigo usei o valor 5, ou seja, o swap só entra em ação com a RAM em 95% de carga.
Lembrando que no Debian por exemplo, este valor é em 40% (o swappiness é 60).

Neste ponto, durante a minha instalação foi o único que eu alterei.
A distribuição iria criar uma partição SWAP, então eu cancelei e não fiz isto, para que posteriormente, criasse via arquivo (seguindo o artigo acima) e colocando o swappiness em 0 (zero).

tmpfs

Para reduzir ainda mais escritas desnecessárias no SSD (se tiver um SSD de 120Gb instalado com o S.O. padrão, sem nenhuma otimização e diariamente gravar e apagar 20Gb de dados no SSD, seu SSD ainda vai tranquilamente funcionar por uns 5 anos ou mais), pode-se mover o diretório /tmp para uma ram disk (temporary Filesystem) utilizando o sistema de arquivos ‘tmpfs’ que é expandido e reduzido dinamicamente quando necessário.
No /etc/fstab:

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0

Esta ultima linha, você abre mão dos logs, perdendo-os a cada reboot! Caso use algum programa que utiliza ou necessita dos dados dentro do diretório /var você pode remover esta linha e inserir manualmente no fstab cada um dos subdiretórios como tmpfs e excluir aqueles que necessita.

Basicamente, numa distro atual (e num SSD novo), apenas fiz 2 alterações (opcionais) na qual eu coloquei alguns diretórios em tmpfs (alterações no fstab), não instalei a SWAP (colocando como arquivo posteriormente) e alterando alguns parâmetros do sysctl.conf para otimizar o uso da memoria.

Muitos artigos que há na internet foram feitos para a tecnologia de 5 anos atrás (ou mais) onde, não só os equipamentos estavam inferiores, mas também as aplicações e o kernel não estavam maduros o suficiente para suporta-los.
Hoje, basta apenas instalar fisicamente e depois, instalar seu Linux.
Podemos passar a era do 'SSD x funciona no linux?' Igual a comunidade passou e enterrou com orgulho a tenebrosa era do "mouse/teclado X funciona no linux?", "impressora Y funciona no Linux?", "Placa-mãe Z roda no Linux?"...

Abaixo o meu laptop ainda com o seu disco comum (Western Digital) de 500Gb.


Troca efetuada pelo SSD Kingston HyperX Savage.
Neste modelo, junto com o SSD vem junto um case para transformar em USB3.0 (na qual coloquei o disco WD que sobrou na troca, ganhando um disco externo), também vem um adaptador para inserir num gabinete 3,5', bem como os cabos sata e 3 chaves para realizar a troca física.



Apesar de ter feito algumas screenshots da instalação do S.O., não achei necessário estender este artigo.
Neste meu notebook usei para os testes o Debian 8, LinuxMint 18.1, usei algumas distros em Live USB (Xubuntu 17.04 beta e 16.10).
Estou usando como S.O. default para o dia-a-dia nele o Manjaro (Arch).
Qualquer coisa, atualizo este artigo acrescentando novas imagens, texto, macetes e experiências com o SSD.


Algumas fontes utilizadas:


Postagens mais visitadas deste blog

TuxMath - Tux, do Comando da Matemática. Ensino e diversão a crianças.

Tux Of Math Command, (Tux, do Comando da Matemática, em sátira ao desenho animado, Buzz Lightyear, do Comando Estelar) ou simplesmente TuxMath é um game open source, no estilo arcade, originalmente desenvolvido para linux, mas atualmente é multiplataforma, disponível em Windows, Mac, BeOS, web, dispositivos móveis...

Melhor desempenho da memória RAM e SWAP no Linux

Melhor desempenho da RAM/SWAP Objetivo: Determinar através do kernel (sysctl) quando o sistema deverá utilizar a memória swap. Com isto, o linux vai usar mais a memória RAM e dar prioridade a ela, ao invés de levar isto para o HD (swap) e deixar alguns processos mais demorados. Por padrão, o valor de swappiness no debian é 60. Ou seja, usará o swap quando a RAM estiver em torno de 40% a 50% em uso. Verificar valor padrão: # cat /proc/sys/vm/swappiness Reduzindo o valor de swappiness para 10 ou 15 (neste exemplo, reduzi para 5), o arquivo de swap será usado apenas quando o uso da RAM chegar em torno de 80 a 90 por cento. Edite: # vim /etc/sysctl.conf Altere (adicione se não existir a linha) no arquivo: # vm.swappiness = 5 (Há quem coloque 0 ou 1, mas prefiro assim) Para evitar a necessidade de reiniciar o sistema, execute: # sysctl vm.swappiness=5 depois, apenas como verificação, execute: # swapoff -a # swapon -a # sysctl -p /etc/sysctl.conf

Tipos de VPNs: PPTP x OpenVPN x L2TP/IPsec x SSTP x IKEv2 x Chameleon x WireGuard

Olá, Baseando-me no formato do artigo sobre Certificados e a sopa de letras: HTTPS, TLS, SSL, HSTS, CA, PGP, GPG e OpenPGP , com o artigo sobre o WireGuard  e a atual crise mundial que forçou muitos em quarentena a trabalhar remotamente, resolvi fazer um semelhante abordando os diferentes tipos de VPN. O principal problema é que ao ler a documentação e artigos atuais, além de longos eles se prolongam muito no detalhe técnico entre elas, então tentei criar um TL;DR (que ficou um pouco grande, mas bem resumido). Uma VPN, ou rede virtual privada, permite criar uma conexão segura entre duas redes ou entre seu dispositivo/host com alguma rede, usando a internet como meio, como túnel para chegar ao destino. As VPNs podem ser usadas para acessar sites restritos por região (países proíbem torrents, outros proíbem redes sociais, sites de noticias...), proteger sua navegação (em redes não confiáveis como hotéis, wifi de lojas, etc...), acessar um sistema corporativo que está instalado e disponív

DHCP - Guia Completo

atualizado em 18/03/2015 Olá a todos, disponibilizo mais um guia ;-) Apesar de um assunto bem fácil, sem segredos ou mistérios, o tema deste guia é DHCP Servers. Nele, abordo o que é o dhcp, como funciona e como configurar. A novidade neste guia é que mostro como realizar a configuração de um servidor DHCP usando roteadores "home / small office", como os famosos d-link, encore, tenda, pacific, tp-link, etc... Como criar um servidor dhcp usando equipamentos Cisco, como habilitar o DHCP Server usando a plataforma Windows (Windows Server 2003), e finalmente usando o GNU/Linux. Claro que meu foco é favorecer o uso do Linux para prover este serviço, para isto, mostro desde a configuração mais simples, até algumas avançadas, tanto em modo texto quanto as mais variadas interfaces gráficas existentes no S.O. para configurar e monitorar este simples serviço de rede. No GNU/Linux, abordo o DHCP Server mais utilizado no mundo (da ISC), as configurações mais utilizadas, o c

Teste de Performance de Rede com Iperf

Troubleshooting,  Throughput,  testes de  conectividade e transmissão de pacotes em rede com Software Livre/Open Source Sumário Base de Conhecimento Rede Local e o tráfego de informações O que é Possíveis situações de uso O Básico - Executando como Server No Windows No GNU/Linux O Básico – o Cliente No Windows No Linux Utilizando UDP Argumentando... Mais Opções Opções gerais -f, --format -i, --interval n -l, --len N -m, --print_mss -o, --output <arquivo> -p, --port n -u, --udp -x, --reportexclude -y, --reportstyle C -w, --window n -B, --bind <host> -M, --mss n -N, --nodelay -V, --IPv6Version Opções para o cliente -P , --parallel -T, --ttl -n, --num -t, --time -d, --dualtest -r, --tradeoff -L, --listenport -b, --bandwidth -F, --fileinput <name> -I, --stdin Opções para o Servidor -s, --server -U, --single_udp -D, --daemon Interface Gráfica em JAVA Conclusão Minha rede está lenta, e agora?? Download e Links Base de Conhecimento O TCP é o protocolo

Colorindo o terminal do Linux

Abaixo, 3 dicas simples para colorir o Linux: Deixar o terminal (bash) colorido; Deixar o vim e o nano colorido; Deixar as manpages coloridas; No bash facilita a identificação de tipos de arquivos, diretórios e permissões (pois cada um terá uma cor diferente). Nos editores de texto, (neste caso o Nano e VIm), as cores facilitam ao criar scripts e programas nas mais variadas linguagens, os esquemas de cores, identificam a sintax da linguagem e colorem de acordo com os comandos, por exemplo, uma cor diferente para scripts entre aspas, comentários, cores diferentes para variáveis, etc... E a melhor de todas as dicas: colorir as manpages! Parece que não, mas facilita muito a vida quando você olha as manpags e enxerga facilmente as flags e opções de cada comando, exemplos e distingui a descrição da opção do comando. Colorindo o Bash Coloque no final do arquivo .bashrc (ele é um arquivo oculto que está dentro do seu /home), é o arquivo de configuração do bash de cada usuário.  

Protocolo RIP - Lab com passo-a-passo em roteadores Cisco

O RIP ou Routing Information Protocol é um protocolo aberto, definido na RFC 1058, e classificado como vetor de distância. As diferenças básicas entre o RIP versão 1 e versão 2 é que o primeiro é classfull, ou seja, suporta apenas classes cheias (A, B ou C) ou subrede com a mesma máscara e troca atualizações de roteamento via broadcast. Já a versão 2 suporta CIDR (classless) e VLSM (divisão de subredes com várias máscaras de subrede), além disso, troca informações através de multicast no endereço 224.0.0.9. Ambas as versões trocam informações utilizando UDP na porta 520. Para IPv6 (versão 6 do protocolo IP) o RIP passa a chamar RIPng (Next Generation) e funciona basicamente da mesma maneira que o RIP versão 2 para IPv4, porém enviando updates no endereço IPv6 de multicast FF02::9. Para configurar o RIP versão 1 basta ativar o protocolo com o comando “router rip”, depois em modo de configuração do roteador definir as redes que serão anunciadas com o comando “network”. No comando

Aula #14 - Os sistemas de arquivos ext2/ext3/ext4

  A família de sistemas de arquivos ext tem sido nativa para o Linux desde os seus primeiros dias, e tem sido a mais utilizada. Até recentemente, o ext4 foi a escolha padrão mais comum das distribuições Linux, devido à sua excelente combinação de desempenho, integridade e estabilidade.

Aula #5 - A estrutura da árvore do Sistema de Arquivos Linux

Existem vários tipos de arquivos presentes em um sistema Linux.  Eles diferem em propósito, tamanho, dono, nível de compartilhamento e volatilidade.  O resultado é uma organização coerente de toda a árvore do sistema de arquivos que é padrão(na medida do possível) entre as distribuições Linux.