e2fsck: blocos ruins desaparecendo!

Question

Senhores,

Eu preciso de alguns conselhos paternos sobre o e2fsck: Eu tenho um disco que está ficando mal-humorado, e o "e2fsck -ccv" estava realmente mostrando blocos ruins. No entanto, reparticionei o disco e agora o mesmo comando informa que o disco está em perfeita saúde! O que aconteceu com meus blocos ruins? É claro que as partições estão todas vazias, mas certamente um bloqueio ruim ainda é um bloqueio ruim? A manutenção interna do disco de alguma forma sinalizou esses blocos para o ponto em que mesmo o e2fsck não dá uma olhada neles? Ou o e2fsck não funciona em partições vazias? Ou um reparo foi feito de alguma forma? Como posso descobrir?

E quais são os aspectos práticos do uso de '-c' vs. '-cc', ou seja, quando e onde eu quero um teste de leitura-gravação versus um teste somente leitura?

E: após o reparticionamento, eu tentei isso: "mkfs.ext4 -vcc ..." na esperança de verificar o disco ao mesmo tempo em que criava o FS, mas isso levava horas e horas. Em contraste: "e2fsck -ccvy ..." depois que o FS foi criado foi muito mais rápido, menos de uma hora para um disco de 500GB com 12 partições. Por quê? É preciso conhecer os fatos da vida antes de começar a checar.

    

Answer 1

As listas de badblock do sistema de arquivos são obsoletas (ignorando os sistemas de arquivos em flash, porque você está falando sobre o ext4). blocos ruins são remapeados pela unidade. Procure por erros - deve haver um registro permanente deles nos contadores SMART. Se você vir um ou mais erros / "blocos ruins" / "setores defeituosos", considere o disco indigno de confiança.

Se seus dados valiosos forem salvos de forma redundante (RAID, backups), algumas pessoas desenvolvem métodos para restabelecer a confiança na unidade durante um período de testes. [*] Você não está usando RAID para começar, então estou não é capaz de recomendar isso.

Esses são os fatos da vida. O comportamento do mkfs v.s. fsck é infeliz. Um teste de leitura / gravação ainda é potencialmente útil para testar uma unidade recém-adquirida. Ele deve levar mais de uma hora, porque a velocidade de E / S do disco está em torno de 100 MB / se você quer gravar e ler todo o disco. (O desempenho relativo dos discos modernos também afeta a viabilidade de certos modos RAID). Também percebo que badblocks -w executa vários passos com padrões diferentes, o que explicaria por que demora tanto tempo. Como as listas de badblock estão obsoletas, você pode executar os badblocks diretamente e procurar por qualquer erro.

No entanto, considerando quanto tempo isso levaria & Se você não puder usar o disco nesse período, talvez prefira usar o teste SMART mais longo disponível ou simplesmente dd if=/dev/sdX bs=10M of=/dev/null e veja se obteve algum erro de leitura.

Os recursos SMART estão disponíveis nos discos do GNOME. (Ele também tem um recurso de referência). Os contadores de erros são medidos em setores; Você pode apenas olhar para todos os contadores que dizem "setores" e verificar se eles são todos zero. Parece que você pode ter alguns em "setores realocados" .

[*] A gravação de novos dados em um setor defeituoso eliminará o erro. Isso funciona escrevendo o setor lógico para um setor físico diferente em uma "área reserva", e a unidade fará o remapeamento de leituras futuras do setor lógico.