Todos nós nos preocupamos em manter nossos dados e arquivos seguros e intactos, mas é possível que os dados sejam danificados e sejam acessados por um usuário sem uma notificação ou aviso de qualquer tipo sobre o problema? A postagem de hoje com perguntas e respostas do superusuário tem a resposta para a pergunta de um leitor preocupado.
A sessão de perguntas e respostas de hoje chega até nós como cortesia do SuperUser – uma subdivisão do Stack Exchange, um grupo de sites de perguntas e respostas voltado para a comunidade.
Foto cortesia de generalização (Flickr) .
A questão
O leitor de superusuário topo morto deseja saber se os dados nos discos rígidos podem degradar e ser acessados sem um aviso sobre o dano:
É possível que a degradação física de um disco rígido possa fazer com que os bits “vire” no conteúdo de um arquivo sem que o sistema operacional perceba a alteração e notifique o usuário sobre isso ao ler o arquivo? Por exemplo, poderia um “p” (binário 01110000) em um arquivo de texto ASCII mudar para “q” (binário 01110001), então, quando um usuário abre o arquivo, ele vê “q” sem estar ciente de que ocorreu uma falha?
Estou interessado em respostas relacionadas a FAT, NTFS ou ReFS (se isso fizer diferença). Quero saber se os sistemas operacionais protegem os usuários disso, ou se devemos verificar nossos dados para variações entre as cópias ao longo do tempo.
Os dados nos discos rígidos podem degradar e ser acessados sem um aviso sobre o dano?
A resposta
O contribuidor do SuperUser Guntram Blohm tem a resposta para nós:
Sim, existe uma coisa chamada bit pod. Mas não, isso não afetará o usuário despercebido.
Quando um disco rígido grava um setor nos pratos, ele não grava apenas os bits da mesma maneira que são armazenados na RAM, mas usa uma codificação para garantir que não haja sequências do mesmo bit muito longas. Ele também adiciona códigos ECC que permitem reparar erros que afetam alguns bits e detectar erros que afetam mais do que alguns bits.
Quando o disco rígido lê o setor, ele verifica esses códigos ECC e repara os dados se necessário (e se possível). O que acontece a seguir depende das circunstâncias e do firmware do disco rígido, que é influenciado pela designação do disco.
- Se um setor puder ser lido e não tiver problemas de código ECC, ele será transmitido ao sistema operacional.
- Se um setor pode ser reparado facilmente, a versão reparada pode ser gravada no disco, lida de volta e depois verificada para determinar se o erro foi aleatório (ou seja, raios cósmicos, etc.) ou se há um erro sistemático com a mídia.
- Se o disco rígido determinar que há um erro na mídia, ele realocará o setor.
- Se um setor não puder ser lido nem corrigido após algumas tentativas de leitura (em um disco rígido designado como disco rígido RAID), o disco rígido desistirá, realocará o setor e informará ao controlador que houve um problema . Ele depende do controlador RAID para reconstruir o setor dos outros membros RAID e gravá-lo de volta no disco rígido com falha, que então o armazena no setor realocado (que esperançosamente não tem um problema).
- Se um setor não puder ser lido ou corrigido no disco rígido de um desktop, o disco rígido fará mais tentativas para lê-lo. Dependendo da qualidade do disco rígido, isso pode envolver o reposicionamento do cabeçote, verificando se há algum bit que se move quando lido repetidamente, verificando quais bits são os mais fracos e algumas outras coisas. Se alguma dessas tentativas for bem-sucedida, o disco rígido realocará o setor e gravará de volta os dados reparados.
Esta é uma das principais diferenças entre os discos rígidos vendidos como discos rígidos “desktop”, “NAS / RAID” ou “vigilância por vídeo”. Um disco rígido RAID pode simplesmente desistir rapidamente e fazer o controlador reparar o setor para evitar a latência do lado do usuário. Um disco rígido de desktop continuará tentando novamente porque fazer o usuário esperar alguns segundos é provavelmente melhor do que dizer que os dados foram perdidos. E um disco rígido de vídeo valoriza as taxas de dados constantes mais do que a recuperação de erros, pois um quadro danificado normalmente nem será percebido.
De qualquer forma, o disco rígido saberá se houve podridão de bits, normalmente se recuperará dele e, se não puder, informará ao controlador que, por sua vez, informará ao driver que informará o sistema operacional. Depois, cabe ao sistema operacional apresentar o erro ao usuário e agir sobre ele. É por isso que o cybernard diz:
- Eu mesmo nunca testemunhei um único erro de bit, mas já vi muitos discos rígidos em que setores inteiros falharam.
O disco rígido saberá se há algo errado com um setor, mas não saberá quais bits falharam. Um único bit que falhou sempre será capturado pelo ECC.
Observe que o chkdsk e os sistemas de arquivos que se reparam automaticamente não tratam do reparo de dados dentro dos arquivos. Eles são direcionados à corrupção dentro da estrutura do próprio sistema de arquivos, como uma diferença no tamanho de um arquivo entre a entrada do diretório e o número de blocos alocados. O recurso de autocorreção do NTFS detecta danos estruturais e evita que afete ainda mais seus dados, mas não repara nenhum dado que já esteja danificado.
Existem, é claro, outros motivos pelos quais os dados podem ser danificados. Por exemplo, a RAM danificada em um controlador pode alterar os dados antes mesmo de serem enviados para o disco rígido. Nesse caso, nenhum mecanismo no disco rígido detectará ou consertará os dados, e esse pode ser um dos motivos pelos quais a estrutura de um sistema de arquivos está danificada. Outros motivos incluem bugs de software, blecautes durante a gravação no disco rígido (embora isso seja resolvido pelo registro do sistema de arquivos) ou drivers ruins do sistema de arquivos (o driver NTFS no Linux foi padronizado como somente leitura por um longo tempo, desde que o NTFS foi submetido à engenharia reversa, não documentado e os desenvolvedores não confiaram em seu próprio código).
- Tive um cenário uma vez em que um aplicativo salvaria todos os seus arquivos em dois servidores diferentes em dois datacenters diferentes para manter uma cópia de trabalho dos dados disponíveis em todas as circunstâncias. Após alguns meses, notamos que cerca de 0,1 por cento de todos os arquivos copiados não correspondiam à soma de verificação MD5 que o aplicativo armazenava em seu banco de dados. Descobriu-se que era um cabo de fibra com defeito entre o servidor e a SAN.
Esses outros motivos explicam porque alguns sistemas de arquivos, como o ZFS, mantêm informações adicionais de soma de verificação para detectar erros. Eles são projetados para protegê-lo de muito mais coisas que podem dar errado do que apenas apodrecer.
Tem algo a acrescentar à explicação? Som desligado nos comentários. Quer ler mais respostas de outros usuários do Stack Exchange com experiência em tecnologia? Confira o tópico de discussão completo aqui .
