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


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

Não é a unidade do sistema operacional; ele está conectado a outra porta SATA e estou tentando copiar arquivos dele para outra unidade saudável.

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

Eu esperaria ver o congelamento apenas para o programa que estou usando para copiar os arquivos (Windows Explorer, etc.), mas em vez disso, todo o meu PC fica irregular e não consigo navegar na Web ou assistir a filmes enquanto copio arquivos da unidade danificada.

A longa história.

Eu moro em uma área rural onde há problemas com eletricidade (brownouts, etc.). Eu mesmo estou usando um no-break e meus próprios discos rígidos estão perfeitamente bem. Mas meus vizinhos geralmente pedem ajuda com seus problemas de PC, e muitas vezes descubro que seus discos rígidos estão danificados, provavelmente devido a problemas de eletricidade. Claro, depois de substituir a unidade danificada, sugiro aos meus vizinhos que comprem uma UPS.

Sempre me perguntei por que meu PC congela totalmente ao recuperar dados de unidades danificadas. É um problema de hardware? Isso é causado pela maneira como o SO lê dados? É algo específico do Windows e não vou experimentar no * nix?

De qualquer forma, a partir de agora eu vou usar algum software dedicado (como o Unstoppable Copier da Roadkil) ao invés do Windows Explorer, embora eu 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 porque as coisas funcionam assim.


125


origem


Usar um gabinete USB externo deve ajudar, já que você não está mais amarrando o disco defeituoso ao controlador SATA do sistema (também, adicionar uma camada extra de hardware sacrificial entre a placa-mãe e um disco defeituoso é sempre uma boa ideia). - Matteo Italia
Não é específico para SATA, os drives IDE também fizeram isso. Também só porque o disco está danificado não significa que o controlador não esteja, especialmente se uma falha elétrica danificar o disco. - Chris H
A resposta aceita é incrível, e contém o que eu ia dizer e muito mais. Basicamente, você está em pânico com o seu controlador SATA, que é um dispositivo de sistema super importante, que, por sua vez, entra em pânico com o Windows. Eu gostaria de saber se habilitar o AHCI / "hot-swap" no BIOS melhoraria a situação. - Arthur Kay


Respostas:


Esta é uma daquelas áreas onde o SATA é sub-ótimo. O problema está no nível do protocolo de interconexão do dispositivo de armazenamento e, portanto, não está relacionado a qual software você está executando. Usar outra copiadora de arquivos ou outro sistema operacional não vai melhorar as coisas magicamente, exceto experimentar para definir diferentes valores de tempo limite para reduzir o impacto do problema (que pode ou não ser possível dependendo do hardware e firmware; veja abaixo).

Existem alguns pontos importantes aqui:

  1. Com 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 tem apenas um único controlador de disco (aquele integrado na placa-mãe), isso significa todo o armazenamento. É ainda pior se a unidade falhar de alguma forma não padrão e / ou inesperada, o que certamente pode acontecer se a unidade for marginal. Você pode estar interessado Como um único disco em uma matriz SATA RAID-10 de hardware pode levar a matriz inteira a uma parada brusca? na falha do servidor.
  2. A maioria dos drives SATA de consumo períodos de tempo limite padrão longos (na ordem dos minutos) e muitos drives SATA do consumidor não têm controle de recuperação de erros. As chamadas unidades "NAS" geralmente têm ERC configurável, e as unidades de alto desempenho praticamente sempre fazem isso; essas unidades também podem ter tempos limite padrão menores (sendo 7 segundos um valor comum). Longos períodos de tempo limite são vantajosos se a unidade contiver a única cópia dos dados, o que infelizmente é comum em sistemas de consumo; eles são uma desvantagem em uma configuração redundante ou em que você simplesmente quer tirar o máximo possível da unidade antes que ela se deteriore ainda mais.
  3. Uma unidade será continue tentando ler um setor ruim até atingir seu limite de tempo limite ou até que um cancelamento seja sinalizado pelo host. Como o barramento SATA pode ser amarrado pela espera pela conclusão da leitura, pode não ser possível para o sistema operacional sinalizar o cancelamento do comando em nível de armazenamento e, em casos extremos, as unidades podem nem responder bem a uma reinicialização do barramento SATA em tal situação.

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

Então o que acontece é que o SO emite um comando "leia setores" para o disco, e os setores específicos estão de alguma forma danificados. Assim, o disco entra em modo de repetição para tentar obter os dados dos pratos, tentando a leitura repetidas vezes até obter dados suficientes que a própria correção de erros do disco (FEC) é capaz de corrigir os erros remanescentes. Se você tiver azar, isso pode ser impossível, mas a unidade continuará tentando por um período de tempo bastante longo antes de decidir que essa leitura não será bem-sucedida.

Como o sistema operacional está aguardando a leitura, isso, no mínimo, desacelerará o processo de cópia para um rastreamento e, dependendo da arquitetura exata do sistema operacional, o sistema operacional pode se tornar irregular ou congelar por enquanto. O disco, neste momento, está ocupado com a leitura original e não responderá a comandos de leitura adicionais até que o que está atualmente sendo executado termine (com sucesso ou sem sucesso), e outro software geralmente não funcionará melhor do que o sistema operacional está sendo executado.

Portanto, qualquer coisa que desencadeie uma leitura em outro lugar (idealmente, somente na unidade danificada) terá que aguardar na fila até que a unidade danificada leia com êxito o setor em questão ou determine que não possa ser lida. Por causa do manuseio de unidades não-responsivas não-ideal da SATA, Isso pode significar que não apenas a unidade da qual você está copiando vai ter sua E / S atrasada. Isso pode facilmente fazer com que outro software se torne lento ou não responda, já que o software aguarda a conclusão de uma solicitação de E / S diferente, mesmo que o sistema operacional seja capaz de lidar com isso.

Também é importante observar aqui que a E / S do disco pode acontecer 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 carga sob demanda e a troca. Como o swap é usado às vezes 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 arquivo executáveis ​​modernos, a atividade de leitura de disco involuntária durante o uso normal é uma possibilidade muito real.

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

Como um pouco de lado, é por isso que o SATA (particularmente, SATA sem ERC no nível do drive) é frequentemente desencorajado por RAID (especialmente Níveis de RAID com redundância, que entre os padrões é tudo exceto 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 do array para um único setor defeituoso, que o controlador RAID poderia manipular bem se a redundância existir e o controlador de armazenamento simplesmente souber que esse é o problema. SAS foi projetado para grandes arrays de armazenamento e, portanto, com a expectativa de que haverá problemas em vários drives 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 graciosamente mesmo que a unidade não. Discos problemáticos não são muito comuns em sistemas de consumo simplesmente porque eles tendem a não ter muitos discos instalados, e os que são instalados virtualmente nunca têm redundância; já que a SATA tinha como objetivo substituir PATA / IDE não SCSI (sendo este último o nicho que a SAS pretendia), é provável que seus recursos e demandas de tratamento de erros (ou garantias) fossem considerados adequados para o caso de uso pretendido.


162



Obrigado por postar uma resposta sensata que explica o que está acontecendo. Esse é o tipo de pergunta em que eu geralmente vejo respostas vagas como "porque o sistema está esperando pela unidade" ou "porque foi projetado dessa maneira". - Mehrdad
@ kasperd: muito bonito. Embora parte dela também seja a "falha" do Windows, como pode acontecer com facilidade com vários controladores. OMI esta resposta é um pouco deliberadamente vago, visto que os controladores SAS corporativos também não estão imunes ao problema. Isso realmente se resume a certas solicitações de E / S de bloqueio. Algumas operações no disco rígido requerem que a operação X seja concluída antes da operação Y, e se X nunca terminar, Y nunca pode começar - e qualquer coisa depois de Y também ficar travado, não importa se a unidade, o controlador, o driver ou o SO está culpa. - qasdfdsaq
@JustAMartin Na verdade, já é quase tudo assíncrono - qualquer periférico que suporte DMA nos dias de hoje está cheio de assíncrono; o kernel apenas agenda os pedidos e manipula as interrupções que sinalizam que o pedido está pronto. O problema é que às vezes você devo aguarde a conclusão da operação - e, no processo, eles podem bloquear algo importante. Como user20574 observou, a memória virtual é uma dessas, mas há muitas coisas que precisam de algumas garantias. Algumas partes do kernel não são assíncronas e, é claro, alguns drivers / dispositivos simplesmente são ruins. - Luaan
@ MichaelKjörling "Como o sistema operacional está aguardando a leitura, isso, no mínimo, desacelerará o processo de cópia para um rastreamento e, dependendo da arquitetura exata do sistema operacional, o sistema pode se tornar irregular ou congelar enquanto durar." - Por que exatamente o sistema operacional fica instável no caso de leitura de uma unidade secundária (sem sistema)? O problema não pode ser inteiramente devido ao comportamento de manipulação de erros do controlador SATA. Eu acho que esta resposta poderia se beneficiar de informações sobre como o Windows lida com erros em seu subsistema de disco. - Jordan Rieger
@ MichaelKjörling Feira suficiente. A resposta tem muitas informações boas, mas acho que isso não explica exatamente o cenário específico do OP. Para chegar a ele de um ângulo diferente, você pode citar qualquer referência para fazer o backup de seu ponto # 1: "Com o SATA, se o drive parar de responder, isso pode comprometer todo o sistema de armazenamento, não apenas o drive que está tendo problemas. Ele certamente tem o potencial de amarrar todo o controle."? Isso parece um projeto terrível. Não é o subsistema de disco do sistema operacional o mais provável culpado? Ou seja o controlador é assíncrono, mas o driver do sistema as vezes bloqueia desnecessariamente. - Jordan Rieger


Como foi dito acima, o problema com o sistema congela devido a um disco rígido ruim é principalmente devido a longas tentativas da unidade para recuperar dados ilegíveis de setores defeituosos. Um dos pontos de venda de drives corporativos é o tempo limite de leitura muito curto para setores com falha. O uso de uma unidade corporativa pode atenuar seus problemas em algum grau, mas não os resolverá.

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


3





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

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

Considere o ZFS, que foi 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 explicando) onde eles colocam corridas em uma bigorna, balançam com uma marreta e perfuram outra unidade. Tudo enquanto o ZFS continua em execução.


2



Na verdade, existem falhas de disco que o ZFS não lida bem. Por exemplo, leituras extremamente longas antes do tempo limite da solicitação de E / S, em configurações redundantes ou não redundantes. (Você pode facilmente configurar o ZFS de modo a não ter redundância.) Isso pode facilmente levar as unidades a serem descartadas da matriz no ZFS, o que, se isso ficar abaixo do limite de redundância, poderá fazer com que toda a matriz tornar-se indisponível. Se configurado com failmode = wait, isso pode mostrar resultados semelhantes. A falha total do disco completo é a fácil caso de qualquer subsistema de armazenamento; Está marginal unidades que apresentam problemas. - Michael Kjörling
E antes que você pense o contrário, eu realmente executo o ZFS (quase exclusivamente). É um ótimo sistema de arquivos e um ótimo gerenciador de volumes, E se você é cuidadoso e sabe o que está fazendo. No entanto, ele é projetado para sistemas de classe empresarial (estações de trabalho e servidores de ponta), com os administradores pagos para saber o que estão fazendo. Ele não foi projetado para lidar bem com alguns modos de falha vistos em hardware comum, incluindo problemas de RAM e unidades que demoram muito tempo para retornar de uma solicitação de E / S, e não foi projetado para facilidade de uso para usuários domésticos ou em Casos de uso do usuário doméstico. - Michael Kjörling
Exceto no vídeo, o ZFS não continua sendo executado. Ele começa a funcionar novamente após desconectar a unidade. - Christoffer Hammarström


Eu acho que o problema que você está encontrando é uma parte de baixo nível do sistema operacional tenta inúmeras vezes para ler os blocos ruins antes de desistir. Essa rotina é implementada em um nível baixo no caso de ser necessária durante a inicialização ou outra operação independente e, portanto, é difícil torná-la reentrante. O sistema operacional irá paginar continuamente durante a operação normal e é difícil dar prioridade a 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.


-2



O 'sistema de baixo nível' faz conhecer a prioridade de um processo que está solicitando uma página; essa informação é realizada em tabelas de páginas, embora a implementação dependa do sistema de como a prioridade é tratada. Esta não é a resposta correta para a pergunta - trata-se de um problema de hardware, não de um sistema operacional. - Chris Cirefice
Eu acho que a resposta correta para a pergunta é se recusar a usar uma unidade defeituosa. No entanto, isso não satisfaria os usuários que, compreensivelmente, desejam recuperar o máximo de dados possível. - jrrk