Por que os discos rígidos danificados congelam todo o sistema?

Por que um disco rígido conhecido por ter blocos defeituosos (verificado no HDTune e HDDScan) congela todo o meu sistema?

Não é a unidade do SO; está anexado a outra porta SATA e estou tentando copiar arquivos para outra unidade íntegra.

Eu enfrentei esse problema com quase todos os discos rígidos danificados e todos os PCs com Windows.

Eu esperava ver o congelamento apenas para o programa que estou usando para copiar os arquivos (Windows Explorer, etc.), mas todo o meu PC fica instável e não consigo navegar na web ou assistir a filmes enquanto copia arquivos da unidade danificada.

A longa história.

Eu moro em uma área rural onde há problemas com eletricidade (quedas de energia, etc.). Eu mesmo estou usando um no-break e meus próprios discos rígidos estão perfeitamente bem. Mas meus vizinhos costumam pedir ajuda com os problemas dos computadores e, geralmente, acho que os discos rígidos estão danificados, provavelmente por causa de problemas de eletricidade. Claro, depois de substituir a unidade danificada, sugiro que meus vizinhos comprem um no-break.

Eu sempre me perguntei por que meu PC congela completamente enquanto recupera dados de unidades danificadas. É um problema de hardware? É causado pela maneira como o sistema operacional lê os dados? É algo específico do Windows, e não o experimentarei no * nix?

De qualquer forma, de agora em diante, usarei algum software dedicado (como a Copiadora Incontrolável da Roadkil) em vez do Windows Explorer, embora não tenha certeza se isso funcionará de maneira diferente, sem congelar o PC inteiro.

_{Não é um pedido de ajuda, é mais para fins educacionais, então eu sei por que as coisas funcionam dessa maneira.}

Essa é uma daquelas áreas em que o SATA é abaixo do ideal. O problema está no nível do protocolo de interconexão do dispositivo de armazenamento e, portanto, não está relacionado ao software que você está executando. O uso de outra copiadora de arquivos ou outro sistema operacional não melhorará magicamente as coisas, exceto que ele pode tentar definir valores de tempo limite diferentes para reduzir o impacto do problema (que pode ou não ser possível, dependendo do hardware e do firmware; veja abaixo )

Existem alguns pontos importantes aqui:

1. Com a SATA, se a unidade parar de responder, isso pode amarrar todo o sistema de armazenamento, não apenas a unidade que está tendo problemas. Certamente tem o potencial de amarrar todo o controlador e, como a maioria dos sistemas de consumo possui apenas um único controlador de disco (o integrado na placa-mãe), isso significa todo o armazenamento. É ainda pior se a unidade falhar de alguma maneira fora do padrão e / ou inesperada, o que certamente pode acontecer se a unidade for marginal. Você pode estar interessado em Como um único disco em uma matriz SATA RAID-10 de hardware pode interromper toda a matriz? na falha do servidor.
2. A maioria das unidades SATA de consumo tem longos períodos de tempo limite padrão (na ordem de minutos) e muitas unidades SATA de consumo não possuem controle configurável de recuperação de erros . As chamadas unidades "NAS" geralmente têm ERC configurável, e as unidades de ponta praticamente sempre têm; essas unidades também podem ter tempos limite padrão mais curtos (7 segundos sendo um valor comum). Longos períodos de tempo limite são vantajosos se a unidade mantiver a única cópia dos dados, o que infelizmente é comum nos sistemas de consumo; elas são uma desvantagem em uma configuração redundante ou onde você simplesmente deseja obter o máximo possível da unidade antes que ela se deteriore ainda mais.
3. Uma unidade continuará tentando ler um setor defeituoso até atingir seu limite de tempo limite ou até que uma interrupção seja sinalizada pelo host. Como o barramento SATA pode ser atrelado à espera pela conclusão da leitura, pode não ser possível para o sistema operacional sinalizar um cancelamento de comando no nível de armazenamento e, em casos extremos, as unidades podem nem responder bem à redefinição do barramento SATA em tal situação.

O ponto 1 é um dos principais pontos de venda do SAS nos servidores; O SAS possui um tratamento de erros significativamente melhor que o SATA. O ponto 2 é uma limitação do firmware da unidade e o número 3 se torna realmente um problema apenas por causa do número 2.

Então, o que acontece é que o sistema operacional emite um comando "setores de leitura" no disco e os setores específicos são danificados de alguma forma. Assim, o disco entra no modo de nova tentativa para tentar obter os dados dos pratos, tentando a leitura repetidas vezes até obter dados bons o suficiente para que a correção de erros ( FEC ) do disco possa corrigir os erros restantes. Se você tiver azar, isso pode nunca acontecer, mas a unidade continuará tentando por um período bastante longo antes de decidir que essa leitura não será bem-sucedida.

Como o sistema operacional está aguardando a leitura, isso reduzirá a velocidade do processo de cópia para um rastreamento e, dependendo da arquitetura exata do sistema operacional, poderá causar espasmos ou até congelar o sistema operacional. O disco, neste momento, está ocupado com a leitura original e não responde a outros comandos de leitura até que o que está sendo executado no momento termine (com ou sem êxito), e outro software geralmente não funcione melhor do que o sistema operacional está sendo executado.

Portanto, qualquer coisa que desencadeia uma leitura em outro lugar ( idealmente , apenas na unidade danificada) terá que esperar na fila até que a unidade danificada leia com êxito o setor em questão ou determine que ela não pode ser lida. Devido ao manuseio menos otimizado da SATA de unidades que não respondem, isso pode significar que não apenas a unidade da qual você está copiando terá sua E / S atrasada. Isso pode facilmente fazer com que outro software fique lento ou sem resposta, pois ele aguarda a conclusão de uma solicitação de E / S diferente, mesmo que o sistema operacional seja capaz de lidar.

Também é importante observar aqui que a E / S do disco pode ocorrer mesmo que você não esteja acessando explicitamente nenhum arquivo no disco. As duas principais causas para isso seriam o código executável de carregamento sob demanda e a troca. Como o swap às vezes é usado mesmo quando o sistema não está sob pressão de memória e o código executável de carga sob demanda é comum em sistemas modernos e com formatos de arquivos executáveis ​​modernos, a atividade não intencional de leitura de disco durante o uso normal é uma possibilidade muito real.

Como apontado em um comentário à pergunta de Matteo Italia , uma estratégia atenuante é usar uma interconexão de armazenamento diferente, que é uma maneira complicada de dizer "coloque o disco em um gabinete USB". Ao abstrair através do protocolo de armazenamento em massa USB , isso isola a parte problemática do SATA do resto do sistema, o que significa que, em teoria , somente a E / S nesse disco específico deve ser afetada por problemas de E / S nesse disco.

Como um pouco de lado, é por isso que o SATA (particularmente o SATA sem ERC no nível da unidade) costuma ser desencorajado para o RAID (especialmente os níveis de RAID com redundância, que dentre os padrões são todos, exceto o RAID 0 ); os longos períodos de tempo limite e a má manipulação de erros podem facilmente fazer com que um dispositivo inteiro seja expulso da matriz por um único setor defeituoso, com o qual o controlador RAID poderia lidar muito bem se existir redundância e o controlador de armazenamento simplesmente sabe que esse é o problema. O SAS foi projetado para grandes matrizes de armazenamento e, portanto, com a expectativa de que ocorram problemas em várias unidades ocasionalmente, o que o levou a ser projetado para lidar com o caso de uma única unidade problemática ou solicitação de E / S normalmentemesmo que a unidade não funcione. Os discos problemáticos não são muito comuns nos sistemas de consumo, simplesmente porque esses tendem a não ter muitos discos instalados e os que são instalados praticamente nunca têm redundância; Como a SATA pretendia substituir o PATA / IDE e não o SCSI (sendo este último o nicho que o SAS pretendia), é provável que seus recursos e demandas (ou garantias) de tratamento de erros tenham sido considerados adequados para o caso de uso pretendido.

Como foi dito acima, o problema com o congelamento do sistema devido a um disco rígido com defeito deve-se principalmente a longas tentativas do disco de recuperar dados ilegíveis de setores defeituosos. Um dos pontos de venda das unidades empresariais é o tempo limite de leitura muito curto para setores com falha. O uso de uma unidade corporativa pode atenuar seus problemas até certo ponto, mas não os solucionará.

A melhor resposta, avançando, é manter backups adequados para que a recuperação não seja necessária. Alterar o software de recuperação não fará diferença, pois esse é um problema de tempo limite do firmware.

Por que os discos rígidos danificados congelam todo o sistema?

Eles não precisam (em geral). É realmente dependendo do sistema de arquivos específico como é tratada uma falha no disco.

Considere o ZFS, projetado desde o início para lidar com bastante tolerância a falhas. Aqui está um vídeo de demonstração (e um com mais explicações ), onde eles colocam os discos em operação em uma bigorna, balançam com uma marreta e perfuram outro disco. Enquanto o ZFS continua em execução.

Acho que o problema que você está enfrentando é uma parte de baixo nível do sistema operacional que tenta inúmeras vezes ler blocos ruins antes de desistir. Essa rotina é implementada em um nível baixo, caso seja necessária durante a inicialização ou outra operação independente e, portanto, é difícil fazê-la voltar a entrar. O sistema operacional pagina continuamente durante a operação normal e é difícil dar prioridade às solicitações concorrentes, porque o sistema de baixo nível não saberá a prioridade do processo que possui uma solicitação de paginação.