¿Por qué los discos duros dañados congelan todo el sistema?


128

¿Por qué un disco duro que se sabe que tiene bloques defectuosos (verificado en HDTune y HDDScan) congela todo mi sistema?

No es la unidad del sistema operativo; está conectado a otro puerto SATA, y estoy tratando de copiar archivos de él a otra unidad en buen estado.

He experimentado este problema con casi todos los discos duros dañados y cada PC con Windows.

Esperaría ver congelación solo para el programa que estoy usando para copiar los archivos (Explorador de Windows, etc.), pero en su lugar, mi PC entera se vuelve irregular, y no puedo navegar por la web o mirar películas mientras copio archivos de la unidad dañada.

La larga historia

Vivo en una zona rural donde hay problemas con la electricidad (apagones, etc.). Yo mismo estoy usando un UPS y mis propios discos duros están perfectamente bien. Pero mis vecinos a menudo piden ayuda con sus problemas de PC, y a menudo encuentro que sus discos duros están dañados, probablemente debido a problemas de electricidad. Por supuesto, después de reemplazar la unidad dañada, sugiero a mis vecinos que compren un UPS.

Siempre me he preguntado por qué mi PC se congela por completo al recuperar datos de unidades dañadas. ¿Es un problema de hardware? ¿Es causado por la forma en que el sistema operativo lee los datos? ¿Es algo específico de Windows y no lo experimentaré en * nix?

De todos modos, de ahora en adelante usaré algún software dedicado (como la Copiadora imparable de Roadkil) en lugar del Explorador de Windows, aunque no estoy seguro de si esto funcionará de manera diferente, sin congelar toda la PC.

No es una solicitud de ayuda, es más para fines educativos, así que sé por qué las cosas funcionan de esa manera.


11
El uso de una carcasa USB externa debería ayudar, ya que ya no está vinculando el disco defectuoso al controlador SATA de su sistema (también, siempre es una buena idea agregar una capa adicional de hardware sacrificable entre su placa base y un disco defectuoso).
Matteo Italia

3
No es específico de SATA, las unidades IDE también hicieron esto. Además, el hecho de que el disco esté dañado no significa que el controlador no lo esté, especialmente si una falla eléctrica dañó el disco.
Chris H

La respuesta aceptada es asombrosa, y contiene lo que iba a decir y mucho más. Básicamente, está entrando en pánico con su controlador SATA, que es un dispositivo de sistema súper importante, que a su vez entra en pánico en Windows. Sin embargo, me pregunto si habilitar AHCI / "hot-swap" en BIOS mejoraría la situación.
Arthur Kay

Respuestas:


170

Esta es una de esas áreas donde SATA es subóptima. El problema está en el nivel de protocolo de interconexión del dispositivo de almacenamiento y, por lo tanto, no está relacionado con el software que está ejecutando. Usar otra copiadora de archivos u otro sistema operativo no mejorará mágicamente las cosas, excepto que podría intentar establecer diferentes valores de tiempo de espera para reducir el impacto del problema (que puede o no ser posible dependiendo del hardware y el firmware; ver más abajo )

Hay algunos puntos importantes aquí:

  1. Con SATA, si la unidad deja de responder, esto puede bloquear todo el sistema de almacenamiento, no solo la unidad que tiene problemas. Ciertamente tiene el potencial de vincular todo el controlador, y dado que la mayoría de los sistemas de consumo tienen un solo controlador de disco (el integrado en la placa base), esto significa todo el almacenamiento. Es aún peor si la unidad falla de alguna manera inesperada o no estándar, lo que ciertamente puede suceder si la unidad es marginal. Te puede interesar ¿Cómo puede un solo disco en una matriz SATA RAID-10 de hardware detener toda la matriz? en la falla del servidor.
  2. La mayoría de las unidades SATA de consumo tienen largos períodos de tiempo de espera predeterminados (del orden de minutos) y muchas unidades SATA de consumo carecen de control de recuperación de errores configurable . Las llamadas unidades "NAS" a menudo tienen ERC configurable, y las unidades de gama alta casi siempre tienen; tales unidades también pueden tener tiempos de espera predeterminados más cortos (7 segundos es un valor común). Los largos períodos de tiempo de espera son ventajosos si la unidad contiene la única copia de los datos, lo que desafortunadamente es común en los sistemas de consumo; son una desventaja en una configuración redundante o donde simplemente desea sacar lo más posible de la unidad antes de que se deteriore aún más.
  3. Una unidad seguirá intentando leer un sector defectuoso hasta que alcance su límite de tiempo de espera o hasta que el host indique un aborto. Dado que el bus SATA puede estar atado por la espera de que termine la lectura, es posible que el sistema operativo no pueda indicar un aborto del comando de nivel de almacenamiento, y en casos extremos, las unidades podrían no responder bien a un reinicio del bus SATA en tal situación.

El punto n. ° 1 es uno de los principales puntos de venta de SAS en servidores; SAS tiene un manejo de errores significativamente mejor que SATA. El punto n. ° 2 es una limitación del firmware de la unidad, y el n. ° 3 se convierte en un problema realmente solo por el n. ° 2.

Entonces, lo que sucede es que el sistema operativo emite un comando de "sectores de lectura" en el disco, y los sectores particulares de alguna manera están dañados. Por lo tanto, el disco pasa al modo de reintento para intentar quitar los datos de los platos, intentando leer una y otra vez hasta que obtenga datos lo suficientemente buenos como para que la corrección de errores ( FEC ) del disco pueda corregir los errores restantes. Si no tiene suerte, es posible que esto nunca suceda, pero la unidad seguirá intentándolo durante un período de tiempo bastante largo antes de decidir que esta lectura no tendrá éxito.

Debido a que el sistema operativo está esperando la lectura, esto al menos ralentizará el proceso de copia a un rastreo, y dependiendo de la arquitectura exacta del sistema operativo puede hacer que el sistema operativo se vuelva irregular o incluso se congele por el tiempo. El disco, en este punto, está ocupado con la lectura original y no responderá a más comandos de lectura hasta que finalice el que se está ejecutando actualmente (con éxito o sin éxito), y otro software generalmente no funcionará mejor que el sistema operativo. se está ejecutando.

Por lo tanto, cualquier cosa que active una lectura en otro lugar ( idealmente , solo en la unidad dañada) tendrá que esperar en línea hasta que la unidad dañada lea con éxito el sector en cuestión o determine que no se puede leer. Debido al manejo menos que óptimo de SATA de las unidades que no responden, esto puede significar que no solo la unidad desde la que está copiando tendrá un retraso de E / S. Esto puede causar que otro software se vuelva lento o no responda, ya que ese software espera a que finalice una solicitud de E / S diferente, incluso si el sistema operativo puede hacer frente.

También es importante tener en cuenta aquí que la E / S de disco puede ocurrir aunque no esté accediendo explícitamente a ningún archivo en el disco. Las dos causas principales para esto serían el código ejecutable de carga a pedido y el intercambio. Dado que el intercambio a veces se usa incluso cuando el sistema no está bajo presión de memoria, y el código ejecutable de carga bajo demanda es común en los sistemas modernos y con formatos de archivo ejecutables modernos, la actividad de lectura de disco no intencionada durante el uso normal es una posibilidad muy real.

Como se señaló en un comentario a la pregunta de Matteo Italia , una estrategia mitigante es utilizar una interconexión de almacenamiento diferente, que es una forma complicada de decir "poner el disco en un gabinete USB". Al abstraer a través del protocolo de almacenamiento masivo USB , esto aísla la parte problemática SATA del resto de su sistema, lo que significa que, en teoría , solo las E / S en ese disco específico deberían verse afectadas por problemas de E / S en ese disco.

Como un aparte, esta es la razón por la cual SATA (particularmente, SATA sin ERC a nivel de unidad) a menudo se desaconseja para RAID (especialmente niveles RAID con redundancia, que entre los estándares es todo excepto RAID 0 ); los largos períodos de tiempo de espera y el manejo deficiente de los errores pueden hacer que un dispositivo completo sea expulsado de la matriz por un solo sector defectuoso, que el controlador RAID podría manejar muy bien si existe redundancia y el controlador de almacenamiento simplemente sabe que este es el problema. SAS fue diseñado para grandes matrices de almacenamiento y, por lo tanto, con la expectativa de que ocasionalmente habrá problemas en varias unidades, lo que llevó a que se diseñara para manejar el caso de una sola unidad problemática o solicitud de E / S con graciaincluso si el disco no lo hace. Los discos problemáticos no son muy comunes en los sistemas de consumo simplemente porque estos tienden a no tener muchos discos instalados, y los que están instalados prácticamente nunca tienen redundancia; Dado que SATA tenía como objetivo reemplazar PATA / IDE, no SCSI (este último es el nicho al que apuntaba SAS), es probable que sus características y demandas (o garantías) de manejo de errores se consideren adecuadas para su caso de uso previsto.


19
Gracias por publicar una respuesta sensata que explique lo que está pasando. Este es el tipo de pregunta en la que generalmente veo respuestas vagas como "porque el sistema está esperando la unidad" o "porque está diseñado de esa manera".
Mehrdad

44
@kasperd: más o menos. Aunque parte de esto también es "falla" de Windows, ya que puede suceder con la misma facilidad con múltiples controladores. En mi opinión, esta respuesta es un poco vaga deliberadamente , ya que los controladores SAS empresariales tampoco son inmunes al problema. Realmente se reduce a ciertas solicitudes de bloqueo de E / S. Algunas operaciones del disco duro requieren que se garantice que la operación X finalice antes de la operación Y, y si X nunca termina, Y nunca puede comenzar, y cualquier cosa después de que Y también se atasque, indique si la unidad, el controlador, el controlador o el sistema operativo están en culpa.
qasdfdsaq

2
@JustAMartin En realidad, casi todo es asíncrono: cualquier periférico que admita DMA en estos días está lleno en asíncrono; el núcleo solo programa las solicitudes y maneja las interrupciones que indican que la solicitud está hecha. El problema es que a veces debes esperar a que se complete la operación, y en el proceso, pueden bloquear algo importante. Como señaló user20574, la memoria virtual es una de esas, pero hay muchas cosas que necesitan algunas garantías. Algunas partes del kernel no son asíncronas y, por supuesto, algunos controladores / dispositivos simplemente apestan.
Luaan

2
@ MichaelKjörling "Debido a que el sistema operativo está esperando la lectura, esto al menos ralentizará el proceso de copia y, dependiendo de la arquitectura exacta del sistema operativo, puede hacer que el sistema operativo se vuelva irregular o incluso se congele por el tiempo". - ¿Por qué exactamente el sistema operativo se vuelve irregular en el caso de leer desde una unidad secundaria (no del sistema)? El problema no puede deberse completamente al comportamiento de manejo de errores del controlador SATA. Creo que esta respuesta podría beneficiarse de la información sobre cómo Windows maneja los errores en su subsistema de disco.
Jordan Rieger

1
@ MichaelKjörling Bastante justo. La respuesta tiene mucha buena información, pero creo que no explica el escenario específico del OP. Para abordarlo desde un ángulo diferente, ¿puede citar alguna referencia para respaldar su punto # 1: "Con SATA, si la unidad deja de responder, esto puede atar todo el sistema de almacenamiento, no solo la unidad que está teniendo problemas . Ciertamente tiene el potencial de atar todo el controlador ". ? Esto parece un diseño terrible. ¿No es el subsistema de disco del sistema operativo el culpable más probable? Es decir, el controlador es asíncrono, pero el controlador del sistema operativo a veces se bloquea innecesariamente.
Jordan Rieger

3

Como se indicó anteriormente, el problema con la congelación del sistema debido a un disco duro defectuoso se debe principalmente a los largos intentos del disco por recuperar datos ilegibles de sectores defectuosos. Uno de los puntos de venta de las unidades empresariales es el tiempo de espera de lectura muy corto para sectores fallidos. El uso de una unidad empresarial puede mitigar sus problemas hasta cierto punto, pero no los resolverá.

La mejor respuesta, en el futuro, es mantener copias de seguridad adecuadas para que no se requiera recuperación. Cambiar el software de recuperación no hará una diferencia ya que este es un problema de tiempo de espera de firmware.


2

¿Por qué los discos duros dañados congelan todo el sistema?

No tienen que hacerlo (en general). Realmente depende del sistema de archivos en particular cómo se trata la falla de un disco.

Considere ZFS, que está diseñado desde cero para lidiar con bastante tolerancia a fallas. Aquí hay un video de demostración (y uno con más explicaciones ) donde colocan unidades en funcionamiento en un yunque, golpean con un martillo y perforan otra unidad. Todo mientras ZFS sigue funcionando.


2
En realidad, hay fallas de disco que ZFS no trata bien. Por ejemplo, lecturas extremadamente largas antes de que se agote el tiempo de espera de la solicitud de E / S, en configuraciones redundantes o no redundantes. (Puede configurar ZFS con la misma facilidad de tal manera que no tenga redundancia). Esto puede conducir fácilmente a que las unidades sean expulsadas de la matriz en ZFS, lo que si esto lo coloca por debajo del umbral de redundancia puede causar que toda la matriz se dejar de estar disponible Si se establece con failmode = wait, esto puede mostrar resultados similares. La falla total del disco completo es el caso fácil para cualquier subsistema de almacenamiento; es marginales unidades que plantean problemas.
un CVn

Y antes de que pienses lo contrario, yo mismo ejecuto ZFS (casi exclusivamente). Es un excelente sistema de archivos y un excelente administrador de volúmenes, si tiene cuidado y sabe lo que está haciendo. Sin embargo, está diseñado para sistemas de clase empresarial (estaciones de trabajo y servidores de alta gama), con los administradores pagados para saber lo que están haciendo. No está diseñado para lidiar bien con algunos modos de falla vistos en el hardware básico, incluidos los problemas de RAM y las unidades que tardan demasiado en regresar de una solicitud de E / S, y no está diseñado para facilitar su uso para usuarios domésticos o casos de uso de usuarios domésticos.
un CVn

Excepto en el video, ZFS no sigue ejecutándose. Comienza a funcionar nuevamente después de desconectar la unidad.
Christoffer Hammarström

-2

Creo que el problema con el que se encuentra es que una parte de bajo nivel del sistema operativo intenta en numerosas ocasiones leer bloques defectuosos antes de darse por vencido. Esta rutina se implementa en un nivel bajo en caso de que sea necesaria durante el arranque u otra operación independiente y, por lo tanto, es difícil hacer que vuelva a entrar. El sistema operativo buscará continuamente durante el funcionamiento normal y es difícil dar prioridad a las solicitudes en competencia porque el sistema de bajo nivel no sabrá la prioridad del proceso que posee una solicitud de paginación.


66
El 'sistema de bajo nivel' hace conocer la prioridad de un proceso que está solicitando una página; dicha información se almacena en tablas de páginas , aunque la implementación depende del sistema de cómo se maneja la prioridad. Sin embargo, esta no es la respuesta correcta a la pregunta: este es un problema de hardware, no un problema del sistema operativo.
Chris Cirefice

1
Creo que la respuesta correcta a la pregunta es negarse a usar una unidad defectuosa. Sin embargo, esto no satisfaría a los usuarios que, comprensiblemente, desean recuperar la mayor cantidad de datos posible.
jrrk
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.