Todos nós nos preocupamos em manter nossos dados e arquivos seguros e intactos, mas é possível que os dados sejam danificados e acessados? por um usuário sem uma notificação ou aviso de qualquer tipo sobre o problema? A postagem de perguntas e respostas do SuperUser de hoje tem a resposta para a pergunta de um leitor preocupado.

A sessão de Perguntas e Respostas vem para nós, cortesia da SuperUser - uma subdivisão do Stack Exchange, um agrupamento de sites de perguntas e respostas.

Foto cedida por generising (Flickr).

A pergunta

SuperUser reader topo morto quer saber se os dados em discos rígidos podem degradar e ser acessado sem um aviso sobre os danos:

É possível que a degradação física de um disco rígido poderia causar bits para “flip” no conteúdo de um arquivo sem o sistema operacional perceber a mudança e notificar o usuário sobre isso ao ler o arquivo? Por exemplo, poderia um “p” (01110000 binário) em um arquivo de texto ASCII mudar para um “q” (binário 01110001), então quando um usuário abre o arquivo, eles vêem “q” sem estar ciente de que ocorreu uma falha?

Estou interessado em respostas relacionadas a FAT, NTFS ou ReFS (se isso faz diferença). Quero saber se os sistemas operacionais protegem os usuários contra isso ou se devemos verificar nossos dados quanto a variações entre as cópias ao longo do tempo.

Os dados dos discos rígidos podem ser degradados e acessados ​​sem um aviso sobre os danos?

Resposta

Colunista do SuperUser Guntram Blohm tem a resposta para nós:

Sim, existe uma coisa chamada bit rot. Mas não, isso não afetará um usuário despercebido

Quando um disco rígido grava um setor nos pratos, ele não apenas grava os bits da mesma maneira que eles são armazenados na RAM, ele usa uma codificação para ter certeza não há sequências do mesmo bit que sejam muito longas. Ele também adiciona códigos ECC que permitem reparar erros que afetam alguns bits e detectam 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 da unidade.

• Se um setor puder ser lido e não tiver problemas de código ECC, ele será passado para o sistema operacional
• Se um setor pode ser reparado facilmente, a versão reparada pode ser gravada em disco, lida de volta, então verificada para determinar se o erro foi aleatório (isto é, 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 com a 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 que esteja designado como um disco rígido RAID), o disco rígido irá desistir, realocar o setor e informar ao controlador que houve um problema. Ele depende do controlador RAID para reconstruir o setor dos outros membros do RAID e gravá-lo no disco rígido com falha, que então o armazena no setor realocado (que, espera-se, não tenha um problema).
• Se um setor não puder ser lido ou corrigido no disco rígido de um computador de mesa, o disco rígido se envolverá em mais tentativas de lê-lo. Dependendo da qualidade do disco rígido, isso pode envolver o reposicionamento da cabeça, verificando se há bits que se alteram quando lidos repetidamente, verificando quais bits são mais fracos e algumas outras coisas. Se qualquer uma dessas tentativas tiver êxito, o disco rígido realocará o setor e gravará os dados reparados.

Essa é uma das principais diferenças entre os discos rígidos vendidos como “desktop”, “NAS / RAID” ou “ vídeo-vigilância ”discos rígidos. Um disco rígido RAID pode simplesmente desistir rapidamente e fazer com que o controlador repare o setor para evitar a latência do lado do usuário. Um disco rígido da área de trabalho continuará tentando de novo e de novo porque ter o usuário aguardando alguns segundos provavelmente é melhor do que dizer que os dados foram perdidos. E um disco rígido de vídeo valoriza taxas de dados constantes mais do que a recuperação de erros, já que um quadro danificado normalmente nem será notado.

De qualquer forma, o disco rígido saberá se houve um pouco de apodrecimento, normalmente se recuperará dele e, se não puder, informará ao controlador que, por sua vez, informará ao driver que informará ao sistema operacional. Então, cabe ao sistema operacional apresentar o erro ao usuário e agir sobre ele. É por isso que cybernard diz:

• Eu nunca testemunhei um único erro de bit, mas tenho visto muitos discos rígidos onde 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 será sempre detectado pelo ECC.

Observe que o chkdsk e os sistemas de arquivos que se auto-reparam automaticamente não corrigem dados de reparo nos 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 detectará danos estruturais e evitará que ele afete ainda mais seus dados, mas não reparará nenhum dado que já esteja danificado.

Existem, é claro, outros motivos pelos quais os dados podem ser danificados. Por exemplo, uma RAM ruim 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 reparará os dados, e isso 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 no diário do sistema de arquivos) ou drivers de sistema de arquivos inválidos (o driver NTFS no Linux padrão permaneceu de leitura por muito tempo desde que o NTFS foi projetado não documentado e os desenvolvedores não confiaram em seu próprio código.

• Eu tive esse cenário uma vez em que um aplicativo salvava todos os seus arquivos em dois servidores diferentes em dois datacenters diferentes para manter uma cópia de trabalho dos dados disponível em todas as circunstâncias. Após alguns meses, notamos que cerca de 0,1% de todos os arquivos copiados não correspondiam à soma de verificação MD5 que o aplicativo armazenava em seu banco de dados. Acabou sendo um cabo de fibra defeituoso entre o servidor e a SAN.

Essas outras razões são por que 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 um pouco de putrefação.

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.

Como priorizar seu feed de notícias no Facebook para iOS

Esta semana, o Facebook finalmente lançou um recurso muito aguardado em seu aplicativo iOS, apelidado de “See First”, que oferece aos usuários um nível ainda maior de controle sobre quem aparece em seu Feed de notícias, como estão organizados e quem é chutado para o meio-fio. As opções estão enterradas sob alguns menus, e classificar toda a confusão entre as páginas que você gostou, as pessoas que você seguiu e os amigos reais na sua lista não é tão fácil quanto parece.

(how-to)

Como inserir caracteres especiais no OS X em dois toques de tecla

Se você é um falante de inglês, às vezes pode ficar perplexo ao inserir caracteres especiais ou acentuados em palavras que não são em inglês. . Existe uma maneira de fazer isso em praticamente todos os sistemas operacionais e dispositivos, mas hoje queremos nos concentrar no OS X. Uma coisa realmente boa sobre teclados com tela sensível ao toque é que eles revolucionaram a forma como inserimos texto.

(how-to)