¿Cuál es la granularidad de un disco duro URE (error de lectura irrecuperable)?


8

tl; dr en caso de que se produzca un URE en un disco duro, ¿perderé 1 bit, 1 Byte o el tamaño de un sector (512 Bytes o 4096 Bytes AF)? y si es posible, explique por qué.

Antecedentes: la pregunta aquí surge cuando un disco duro tiene un problema para leer datos. Seguramente un disco puede fallar por completo y perder todos sus datos (DISK FAIL), pero el caso sobre el que pregunto aquí es que cuando solo se pierde una parte más pequeña (URE, un error de lectura no corregible).

Aunque he buscado información sobre URE, he descubierto poco con certeza. Esto podría tener su causa en que lo que sucede internamente en el disco, es decir, lo que está oculto de la interacción directa del usuario, como la corrección de ECC, es difícil para mí relacionarme con lo que accedo como usuario: los sectores.

Imaginemos que el disco duro tiene problemas para leer los datos.

En esa situación, seguramente esto debe significar que:

  • (a) algunos bits del sector no se pueden leer, o
  • (b) todos los bits se pueden leer, sin embargo, no pasan una prueba de suma de comprobación (por supuesto, esperando problemas un sector 4096 Byte no es solo 8 * 4096 bits, sino algunos bits / byte adicionales para la verificación / corrección de errores (es decir, bits de paridad ) (C) ????

No, creo que cuando estamos en la situación en la que se produjo una combinación de (a) y (b) y no se puede realizar una reconstrucción confiable de los bytes del sector 4096, entonces es excesivo suponer que necesariamente todos son garpage , en realidad, si estuviéramos al tanto de la lógica de corrección de errores del disco duro interno, en su lugar podríamos decir "mira, algo no se verifica, y con un buen cambio al menos 1,2,3, n bits / bytes de los datos del bloque están" mal " ". Si estuviéramos guardando redundantemente cadenas de bytes ASCII "hola, hola ....., hola" en este sector, aún podríamos tener una sucesión justa de "hola, hola ..." antes de que haya un "... Uellohello ... "(es decir," e "->" U ").

Entonces, ¿cuál es la granularidad de una URE?

ACTUALIZACIÓN: ha habido un comentario que introduce la idea del sector defectuoso (y sugiere que esto refleja la granularidad de un evento URE. No es absurdo sugerirlo y tal vez pueda usarse para responder a la pregunta. Sin embargo, acabo de leer otro relacionado pregunta sobre sectores ilegibles pendientes (aquí /unix/1869/how-do-i-make-my-disk-unmap-pending-unreadable-sectors ) que me lleva a pensar que en algunos En los escenarios hay una línea más borrosa entre los datos perdidos en caso de una URE.


Por lo general, hay decenas de miles de bloques dañados a la vez en el caso de una cabeza estrellada. Si se trata de polvo, etc., acceder a los bloques cercanos puede propagar el daño. Por lo tanto, rara vez es tan simple como parte de un área más grande que se puede reconstruir.
JamesRyan

@JamesRyan buena pista, siempre puede ser peor. Tal vez simplemente estaba preguntando sobre el caso menos malo posible (eso es solo para perder un sector, o como se resolvió en parte en las buenas respuestas, una parte de los datos de los sectores, dependiendo del tipo dentro de él). quizás sea necesario saber más sobre la génesis de los errores ilegibles (y su persistencia, es decir, pudrición aleatoria de bits, frente al impacto del choque de la cabeza). Pero queremos preguntas que respondan aquí, así que ya no complicaba innecesariamente la pregunta
humanidad y la

Respuestas:


8

El código de corrección de errores en un disco duro es una porción adicional de datos que está asociada con cada sector de hardware. Durante la escritura, el firmware de la unidad calcula estos datos y los escribe junto con los datos del usuario. Durante la lectura, el firmware lee el ECC junto con los datos y los verifica juntos.

Para un disco duro tradicional, el sector del hardware es de 512 bytes. Para una unidad de formato avanzado, es de 4K bytes (no importa si la unidad presenta sectores de 512 bytes o de 4K bytes en la interfaz, es decir, 512e frente a 4kn).

El resultado de la verificación después de una lectura tiene básicamente tres resultados posibles:

  • sector fue leído sin error. En realidad, esto no es completamente común en los discos duros modernos; Las densidades de bits son tales que dependen del funcionamiento de ECC.

  • sector fue leído con errores corregibles. Como se indicó anteriormente, esto no es infrecuente; se espera La unidad devuelve los datos, con la corrección de errores aplicada, al usuario.

  • se leyó el sector pero había demasiados "bits incorrectos"; los errores no pudieron ser corregidos.

En este último caso, la unidad normalmente no devuelve ningún contenido; solo devuelve un estado que indica el error. Esto se debe a que no es posible saber qué bits son sospechosos, y mucho menos cuáles deberían ser sus valores. Por lo tanto, todo el sector (bits ECC y todo) no es confiable. Es imposible determinar qué parte del sector defectuoso es malo, y mucho menos cuál debería ser su contenido. El ECC es una "gestalt" que se calcula en todo el contenido del sector y, si no coincide, es el sector completo el que no coincide.

SpinRite funciona simplemente tratando de leer el sector defectuoso una y otra vez, utilizando una función de "lectura de mantenimiento" que devuelve los datos (pero sin bits ECC) a pesar de que la unidad dice "error no corregible". Como se dijo en la descripción vinculada por DavidPostill, puede tener éxito con una lectura sin errores (en realidad, "corregible" es más probable); o puede ser capaz de deducir, esencialmente promediando los bits devueltos juntos, una estimación razonable del contenido del sector. No tiene más capacidad para corregir errores con precisión utilizando el ECC que la unidad; Eso es matemáticamente imposible.


¿Sigue siendo matemáticamente imposible si los datos dentro de la carga útil de 4096 Bytes eran en sí mismos una combinación de una carga útil de 4000 Bytes y otra ECC de 96 Bytes en la parte superior? (por ejemplo, porque estaba dispuesto a sacrificar la capacidad de recuperación en el diseño del almacén de datos?).
humanityANDpeace

Supongo que es matemáticamente imposible bajo el supuesto implícito de que no hubo más redundancia dentro de los datos, ¿verdad? - ¡Y también una gran respuesta!
humanityANDpeace

1
Por supuesto. En ese momento, es solo otro canal poco confiable, pero si hay suficiente redundancia en él ... El problema es que los controladores de disco estándar del sistema operativo no le darán el contenido del sector si la unidad cree que los errores no son corregibles. RAID-5 y esquemas de paridad similares están haciendo lo mismo en una "capa externa" en lugar de dentro de los campos de datos de los sectores existentes.
Jamie Hanrahan

"la trampa" con los controladores del sistema operativo para devolver (a pedido) todo, incluso los datos no verificados es un problema, como usuario que no es de Windows, pregunté sobre esto específicamente unix.stackexchange.com/questions/228254/…
humanityANDpeace

3

¿Cuál es la granularidad de una URE?

Los errores de lectura irrecuperables (URE) son fallas de lectura del sector. Si el sector no puede leerse sin error, no importa si era solo 1 byte o todos los bytes del sector.

La granularidad es el tamaño del sector .

Incluso si solo fallara 1 byte, normalmente no recuperará ninguno de los datos de ese sector sin utilizar un software especializado.


¿Se pueden recuperar los datos de un sector fallido?

SpinRite dice:

SpinRite incluso puede recuperar la mayoría de los datos en un sector que nunca puede leerse perfectamente y que cualquier otro software de utilidad descarta por completo.

Vea cómo SpinRite recupera datos ilegibles .


Descargo de responsabilidad.

No estoy afiliado a SpinRite de ninguna manera, y nunca lo he usado.


1
Tiendo a pensar que esta es una buena respuesta, no porque necesariamente esté de acuerdo en que en caso de una URE es necesario perder un sector (es decir, después de todos los 4k de datos) por completo, sino porque el disco duro podría descartar incluso esa parte del "mal sector" que aún sería de valor. La presentación de los argumentos de SpinWrite sustenta esta idea, por lo que la respuesta también ofrece más información, excelente.
humanityANDpeace

2

No existe tal cosa como "no se puede leer un poco", a menos que tenga un error de hardware realmente grave, como que el cabezal no pueda buscar la pista correcta o que la pista del servo esté dañada y no se pueda encontrar el sector correcto . Obviamente, en cualquier caso, tendría, como mínimo, todo un sector ilegible.

De lo contrario, siempre se recuperan bits, son posiblemente bits incorrectos . Aquí es donde entra el código de corrección de errores; agrega cierto número de bits ECC adicionales a cada sector, de modo que cualquier combinación correcta de bits de datos y bits ECC observe alguna regla algebraica. Si todos los bits se leyeron correctamente, el código se validará y los datos se pueden devolver directamente. Si se leyó incorrectamente un pequeño número de bits, el código ECC se puede usar para determinar exactamente cuáles y corregirlos, de modo que todos los datos se devuelvan correctamente. Si se lee incorrectamente un número mayor de bits, el código ECC puede detectar que no fue un error, pero ya no tiene suficiente información para averiguar lo que los bits son incorrectos; Este es un error de lectura no corregible. Si unse lee incorrectamente un número muy grande de bits, entonces el código podría validarse correctamente "por accidente" y la unidad devolverá datos corruptos, pero con suficientes bits ECC la probabilidad de que esto ocurra puede ser tan pequeña como desee.

Entonces, para responder la pregunta, creo que estaba llegando: si hubo un error de lectura parcial pero había suficiente información disponible para descubrir dónde ocurrió el error, entonces también se puede corregir, y la computadora no verá ningún error en absoluto . Esto realmente sucede constantemente. Se produce un error no corregido cuando no es posible determinar qué bits de datos son válidos y cuáles no, y dado que el código de corrección de errores se calcula sobre un sector, esto ocurre con granularidad de sector.


1

Después de haberlo examinado e inspirado por la respuesta https://superuser.com/a/969917/160771 de https://superuser.com/users/337631/davidpostill

Me gustaría responder presentar una respuesta alternativa algo amplia. Primero, es cierto que el disco duro y su firmware son el origen de un evento URE, es decir, el evento de que los datos no pueden leerse. Además, es cierto que los datos se escriben en el disco en sectores de 512 o 4096 bytes de datos utilizables y unos 50 o 100 bytes respectivos de datos adicionales que deberían permitir la verificación y corrección de errores.

Hablar sobre un URE ocurre, por lo tanto, naturalmente en el contexto de un sector de disco duro. El término mal sector seguramente está algo vinculado, pero no es idéntico a la situación actual cuando tenemos un sector URE.

Un sector con algunos problemas para ser leído sin error, no es necesariamente completamente sin sentido. Podría ser que, de hecho, todos los 4096 de datos se hayan dañado, pero también podría ser que solo 1 bit más de lo que se podía corregir de manera confiable (a través de los datos ECC adicionales agregados a cada sector) estaba dañado.

En algunos casos, en los que solo unos pocos bytes más de los que el disco duro pudo corregir se corrompieron, hay cambios que la fracción de los 4096 bytes aún tiene datos significativos.

Un ejemplo podría ser que el 4096 representa los charbytes ASCII de 2 oraciones. Entonces es posible que 1 oración o más esté completamente intacta. También podría ser posible que cada 2da o 3ra letra haya sido eliminada. Si los datos de 4096 se pierden en un evento URE, depende de la interpretación y dependen de los datos. Se podría imaginar que los datos en sí mismos tenían otra capa de shell ECC, lo que permitiría una mayor recuperación.

Por lo tanto, es bueno que la mayoría de los firmwares traten a los sectores de URE de manera diferente a los sectores defectuosos:

Por lo general, la reasignación automática de sectores solo ocurre cuando se escribe en un sector. La lógica detrás de esto es presumiblemente que incluso si un sector no se puede leer normalmente, aún puede ser legible con métodos de recuperación de datos. (de https://en.wikipedia.org/wiki/Bad_sector )

O, en cierta medida, podría ser que una parte del sector todavía contiene datos utilizables.


Tenga en cuenta que el artículo está marcado como "necesita atención de un experto", "posiblemente contiene investigación original" y esa declaración particular está marcada como "cita requerida". La forma en que está escrito ("presumiblemente") también hace que suene como si alguien estuviera especulando, en lugar de algo que se pueda corroborar con material de origen de alta calidad.
un CVn el
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.