O TRIM evita o impacto no desempenho do mdadm RAID 1 no SSD?

Question

Já foi mencionado em outras questões que a Red Hat não recomenda o uso do mdadm RAID 1 no SSD.

A Red Hat também alerta que os níveis 1, 4, 5 e 6 de RAID de software não são recomendados para uso em SSDs. Durante o estágio de inicialização desses níveis de RAID, alguns utilitários de gerenciamento de RAID (como o mdadm) gravam em todos os blocos do dispositivo de armazenamento para garantir que as somas de verificação funcionem corretamente. Isso fará com que o desempenho do SSD diminua rapidamente.

Eu entendo o raciocínio por trás disso. No entanto, suspeito que isso tenha sido escrito antes da chegada demdtrim, que foi projetado especificamente para mdadm RAID 1. Isso evita o problema? Se meu entendimento do TRIM estiver correto, acredito que sim, mas não tenho certeza, por isso estou perguntando.

TRIM pode não ser adequado para mim. Eu preciso disso para um sistema de produção e o mdtrim parece, na melhor das hipóteses, experimental. Mais importante ainda, preciso de criptografia forte epesquisarmostrou que o TRIM revela um pouco demais ao destacar quais partes da unidade estão realmente em uso. Existe alguma maneira de evitar o problema de desempenho e ainda ter uma criptografia forte? Fiquei me perguntando se era possível fazer um TRIM parcial, liberando alguns blocos para desempenho, mas não tantos a ponto de revelar muito.

Uma sugestão que vi foi usar apenas cerca de 80% de cada disco para que, após o mdadm fazer sua verificação inicial, ainda restassem alguns blocos não utilizados. Mas esses blocos não seriam os primeiros a serem utilizados na utilização posterior do disco? Eles ainda se esgotariam rapidamente e então eu não estaria em melhor situação, certo?

Answer 1

Claro, você pode fazer um corte parcial com mdtrim (consulte --reservea opção) para sempre deixar alguma quantidade de espaço livre sem corte. Ou você pode simplesmente criar um arquivo grande com dd(1) em seu FS criptografado para usar algum espaço, que nunca será cortado (nem usado por você). Acho que cortar quase 30% do espaço não utilizado proporcionará muitos benefícios de desempenho, sem comprometer muito a segurança.

você pode (como você sugere) fazer superprovisionamento em vez de cortar (em SSD novo ou apagado com segurança pelo ATA), criando uma partição com apenas 80% de espaço e usá-la. Não "se esgotará rapidamente e então você não estará em melhor situação". Aqui está o porquê:

Suponha (para simplificar) que seu disco tenha 10.000 setores (LBAs). Ao particionar de forma que apenas metade seja usada (novamente para simplificar), você usará apenas o LBA 0-4999, enquanto o LBA 5000-9999 nunca será tocado. Agora, o firmware de uso nivelado na unidade tem duas maneiras de saber quais setores não são utilizados - aqueles que seu sistema operacional especificado pelo TRIM e aqueles que estão sendo reescritos. Portanto, se você escrever no LBA 100 pela primeira vez, ele será usado (por exemplo, no bloco físico 123). Quando você grava no LBA 100 pela segunda vez, o SSD irá gravá-lo em um novo local (por exemplo, bloco físico 124) e então marcará a versão ANTIGA do LBA 100 (que é o bloco físico 123) como não utilizada (TRIMed), para que posteriormente quando o SSD está ocioso, ele pode fazer a coleta de lixo e (se todos os outros blocos físicos nesse bloco de apagamento também não forem utilizados), apagar todo o bloco de apagamento (que é muito maior que o bloco de gravação físico - por exemplo, 512 KB vs 4 KB)

Portanto, ao reduzir pela metade o alcance de LBAs usados, você aumentou o número de setores físicos superprovisionados que a unidade pode usar. Eles não ficarão "usados", mas você precisa ter o suficiente deles para que a fragmentação neles (blocos físicos parcialmente usados ​​e parcialmente não utilizados no mesmo bloco de apagamento) desapareça antes que você fique sem espaço livre (caso contrário, o firmware do SSD precisará copiar os blocos usados ​​para outro local antes de apagar todo o bloco de apagamento, levando assim à amplificação de gravação, baixo desempenho e redução da vida útil do SSD)

O comando TRIM ainda é útil porque acelera esse processo (e sem perder tanto espaço), marcando setores não utilizados antes que precisem ser gravados novamente (e assim também evitando gravação extra e prolongando a vida útil do SSD).

Answer 2

Para aumentar a resposta antiquada, substituí recentemente um HDD com falha no meu RAID1 por um SSD. A partir dos experimentos e pesquisas que conduzi, descobri o seguinte:

• O Linux md passa por comandos TRIM para as unidades constituintes desde ~2.6.39, mas somente se todos eles suportarem o comando TRIM.
  • Para meu HDD + SSD RAID1, tive que falhar e remover o HDD, executar o TRIM e depois --re-addo HDD.
• O TRIM pode ser feito em um dispositivo de bloco quente usando fstrim, o Linux md irá então retransmitir isso para o SSD.
• A recuperação RAID1 inicial gravará em todo o SSD.
• O script mdtrim ainda é experimental e não é atualizado há anos.
• Ao usar o TRIM nos blocos excessivamente gravados, o espaço pode ser liberado aos olhos do firmware do SSD e melhorar o desempenho, reduzir a amplificação de gravação e muito mais.