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


128

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.


11
Usar um gabinete USB externo deve ajudar, pois você não está mais vinculando o disco defeituoso ao controlador SATA do sistema (também é sempre uma boa ideia adicionar uma camada extra de hardware sacrificável entre a placa-mãe e um disco defeituoso).
Matteo Italia

3
Não é específico para a SATA, as unidades IDE também fizeram isso. Também porque o disco está danificado não significa que o controlador não esteja, especialmente se uma falha elétrica danificar o disco.
21715 Chris H das

A resposta aceita é incrível e contém o que eu ia dizer e muito mais. Basicamente, você está entrando em pânico no seu controlador SATA, que é um dispositivo de sistema super importante, que por sua vez entra em pânico no Windows. Eu me pergunto se a ativação do AHCI / "hot-swap" no BIOS melhoraria a situação.
Arthur Kay

Respostas:


170

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.


19
Obrigado por realmente postar uma resposta sensata que explica o que está acontecendo. Esse é o tipo de pergunta em que geralmente vejo respostas vagas como "porque o sistema está aguardando a unidade" ou "porque foi projetado dessa maneira".
Mehrdad

4
@kasperd: Praticamente. Embora parte disso também seja uma "falha" do Windows, pode acontecer com a mesma facilidade com vários controladores. Na IMO, essa resposta é um pouco deliberadamente vaga , visto que os controladores SAS corporativos também não são imunes ao problema. Realmente se resume a certas solicitações de E / S de bloqueio. Algumas operações do disco rígido exigem que a operação X seja garantida para ser concluída antes da operação Y e, se X nunca terminar, Y nunca poderá começar - e qualquer coisa após Y ficar travada também, não importa se a unidade, o controlador, o driver ou o SO está em culpa.
precisa saber é o seguinte

2
@JustAMartin Na verdade, já é quase tudo assíncrono - qualquer periférico que suporte DMA atualmente está cheio de forma assíncrona; o kernel apenas agenda as solicitações e lida com as interrupções que sinalizam que a solicitação foi feita. O problema é que, às vezes, é necessário aguardar a conclusão da operação - e, no processo, eles podem bloquear algo importante. Como o usuário20574 observou, a memória virtual é uma dessas coisas, 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 11/08/2015

2
@ MichaelKjörling "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, pode causar espasmos ou até congelar o sistema operacional". - Por que exatamente o sistema operacional fica instável no caso de ler de uma unidade secundária (não do sistema)? O problema não pode ser inteiramente devido ao comportamento de manipulação de erros do controlador SATA. Eu acho que essa resposta poderia se beneficiar de informações sobre como o Windows lida com erros em seu subsistema de disco.
Jordan Rieger

1
@ MichaelKjörling Fair bastante. A resposta tem muitas informações boas, mas acho que não explica bem o cenário específico do OP. Para chegar a esse ponto de vista de um ângulo diferente, você pode citar qualquer referência para fazer backup do seu ponto 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 ". ? Parece um design terrível. Não é o subsistema de disco do SO o culpado mais provável? Ou seja, o controlador é assíncrono, mas o driver do SO algumas vezes bloqueia desnecessariamente.
111115 Jordan Rieger

3

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.


2

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.


2
Na verdade, existem falhas de disco com as quais 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 configurar o ZFS com tanta facilidade que não possui redundância.) Isso pode facilmente levar as unidades a serem lançadas para fora da matriz no ZFS, o que, se ficar abaixo do limite de redundância, pode fazer com que toda a matriz ficar indisponível. Se definido com failmode = wait, isso pode mostrar resultados semelhantes. Falha total no disco completo é o caso fácil para qualquer subsistema de armazenamento; são unidades marginais que apresentam problemas.
um CVn

E antes que você pense o contrário, eu realmente corro o ZFS (quase que exclusivamente). É um ótimo sistema de arquivos e um gerenciador de volume maravilhoso, se você for cuidadoso e souber o que está fazendo. No entanto, ele foi projetado para sistemas de classe empresarial (estações de trabalho e servidores sofisticados), com administradores pagos para saber o que estão fazendo. Ele não foi projetado para lidar bem com alguns modos de falha observados em hardware comum, incluindo problemas de RAM e unidades que demoram muito para retornar de uma solicitação de E / S, e não foi projetado para facilitar o uso de usuários domésticos ou em casos de uso de usuário doméstico.
um CVn

Exceto no vídeo, o ZFS não continua em execução. Ele começa a funcionar novamente depois de desconectar a unidade.
Christoffer Hammarström

-2

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.


6
O 'sistema de baixo nível' faz saber a prioridade de um processo que está solicitando uma página; essas informações são mantidas 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 - este é um problema de hardware, não um problema de SO.
precisa saber é o seguinte

1
Eu acho que a resposta correta para a pergunta é recusar-se a usar uma unidade defeituosa. No entanto, isso não satisfaria usuários que compreensivelmente desejam recuperar o máximo de dados possível.
Jrrk
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.