Início / unix / Perguntas / 756248
Accepted
vinc17
Asked: 2023-09-11 20:58:13 +0800 CST

SSD: `badblocks` / `e2fsck -c` vs setores realocados/remapeados

  • 772

O badblocksutilitário permite encontrar blocos defeituosos em um dispositivo e e2fsck -cadicionar esses blocos defeituosos ao inode do bloco defeituoso para que eles não sejam usados ​​para dados reais. Mas para SSD, sabe-se que setores defeituosos são normalmente realocados (remapeados) de forma transparente pela unidade (no entanto, somente quando ocorre uma gravação). Então, faz algum sentido usar badblocks/ e2fsck -cem um SSD?

eu suponho que

  • badblockspor si só pode fazer sentido obter informações sobre a saúde do SSD, por exemplo, considerando o número total de blocos defeituosos (não sei se o smartctlsmartmontools pode fazer a mesma coisa... talvez com um teste longo smartctl -t long, mas não consegui). não vi nenhuma documentação clara);
  • seu uso deve ser desencorajado e2fsck -c(que adiciona blocos defeituosos ao inode de bloco defeituoso), pois devido à possível realocação, os números associados (endereços lógicos?) podem se tornar obsoletos.

Mas não há nenhum aviso sobre o caso do SSD nas páginas de manual desses utilitários. Então estou me perguntando...

ssd

1 respostas

  1. Best Answer

    Os discos rígidos também remapeiam setores com falha nas gravações, e têm feito isso há décadas; isso não é específico para SSDs. O principal problema com badblocksos SSDs em comparação com os discos rígidos é a quantidade de desgaste que a gravação de uma unidade inteira acarreta (mas mesmo isso não é necessariamente significativo).

    Este remapeamento (que não afeta identificadores de bloco visíveis externamente) significa que usar badblockspara evitar a gravação em um bloco é inútil - quando um bloco defeituoso é encontrado, é realmente melhor escrever nele, para que a unidade possa remapeá-lo, se necessário . E usar badblockspara identificar blocos que não podem ser lidos também não é particularmente útil; se os dados forem importantes, é melhor usar uma ferramenta para ddrescuetentar recuperá-los, e se os dados não forem importantes, é melhor sobrescrever o bloco para que a unidade possa remapeá-los se necessário.

    Os próprios testes das unidades podem ser usados ​​para identificar blocos defeituosos; para isso, a melhor opção é o teste offline, pois é ele que atualiza mais campos de rastreamento de erros (e assim verifica mais erros). Se você executar isso periodicamente e procurar contagens de setores “offline incorrigíveis” diferentes de zero, deverá obter o mesmo resultado que executar badblocks. (Execute smartctl -ae observe os campos que possuem “Offline” na coluna “Atualizado”.)

    De qualquer forma, em unidades modernas, se a unidade ficar ruim o suficiente para que seu remapeamento não consiga lidar e, portanto, excluir blocos de um sistema de arquivos seria útil, então é hora de reciclá-la.

    Veja também o wiki do Arch para uma discussão sobre badblocksv. remapeamento. badblockspode ser usado para forçar a identificação de blocos defeituosos pelo firmware da unidade, mas suspeito que uma abordagem mais direcionada (pelo menos durante a gravação) seria preferível em um SSD.

    • 1

relate perguntas