Esta es la segunda vez que recibo este error badblocks, aproximadamente con 2 años de diferencia desde la última vez, y la gran mayoría de factores, desde el hardware (cables, etc.) hasta el software (la instalación del sistema operativo en sí) han cambiado. ya que, siendo los únicos factores comunes relevantes Cygwinel badblocksprograma en sí, es muy probable que el problema esté entre ellos.
Cuando ejecuto badblocksen modo destructivo (es decir, con el -winterruptor), aparece el error:
Valor extraño (4294967295) en do_writerrors
...en cada etapa de escritura de los patrones en la unidad.
Por lo que puedo decir, parece que recibo este error solo cuando ejecuto el comando con el último bloque especificado informado por fdisk -l:
$ fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
$ badblocks -b 512 -vws /dev/sda 1953525168 1953525168
Checking for bad blocks in read-write mode
From block 1953525168 to 1953525168
Testing with pattern 0xaa: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: 1953525168ne, 0:00 elapsed. (0/0/0 errors)
done
Testing with pattern 0x55: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0xff: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0x00: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Pass completed, 1 bad blocks found. (1/0/0 errors)
$ badblocks -b 512 -vws /dev/sda 1953525168 1950000000
Checking for bad blocks in read-write mode
From block 1950000000 to 1953525168
Testing with pattern 0xaa: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: 1953525168ne, 0:49 elapsed. (0/0/0 errors)
done
Testing with pattern 0x55: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0xff: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0x00: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Pass completed, 1 bad blocks found. (1/0/0 errors)
Como puede verse, esto también resulta en un falso positivo de un bloque defectuoso, mientras que este supuesto bloque defectuoso no se encuentra por ninguna parte a través de CrystalDiskInfo:
En este punto, la unidad se puso a cero varias veces y se badblocksescribió en sus últimos bloques decenas de veces, por lo que hubo muchas oportunidades para que los valores SMART hayan detectado un sector defectuoso en el bloque, 1953525168si existiera alguno.
¿Qué significan realmente estos errores y qué podría estar causándolos?
Respuesta1
Aunque harrymc podría haberle dado el núcleo de mi respuesta (es decir, 4294967295como -1) unsigned int, no explicó con más detalle por qué badblocksno simplemente lo "reconoce" como -1(es decir, por qué aparece el error de "valor extraño" con una compilación Cygwin en Windows ).
Eché un vistazo al código de badblocksCygwin:
https://github.com/tytso/e2fsprogs/blob/v1.45.4/misc/badblocks.c#L463
Y se me ocurrió esto:
[tom@archlinux ~]$ cat test.c
#include <stdio.h>
unsigned int eh() {
return -1;
}
int main() {
long got;
got = eh();
printf("%ld\n", got);
got = (long) eh();
printf("%ld\n", got);
got = (int) eh();
printf("%ld\n", got);
}
[tom@archlinux ~]$ cc test.c
[tom@archlinux ~]$ ./a.out
4294967295
4294967295
-1
[tom@archlinux ~]$
Básicamente, esto quiere decir que si desea interpretar una variable sin signo (que puede usarse intencionalmente para almacenar un valor con signo) como una variable con signo, debe interpretarla con su propio tamaño, pero no con el tamaño de otra variable que vaya a utilizar. poner su valor.
No estoy exactamente familiarizado con la programación, pero como puede ver, el (_ssize_t)tipo de conversión reent/writer.cprobablemente sea incorrecto. Si asumimos _write()que es del inttipo (o cualquier tipo con signo), dicha conversión de tipos es redundante. Si asumimos _write()que es del unsigned inttipo, entonces el tipo de conversión que necesita debería ser (int). (Para que conste, es necesario sólo porque estamos "expandiendo" su valor a _ssize_t(es decir ret). Una comparación como (an_unsigned_int == -1)podría funcionar bien, AFAIK.)
Aunque tengo que decir que esto es simplemente mi suposición, ya que realmente no sé acerca de los _write()usos de Cygwin (por ejemplo, si tiene algo que ver coneste, y si es así, si la documentación es simplemente basura). Pero creo que es un caso válido para unainforme de error, lo que podría ayudarle a obtener más información.
Actualizar:Estepodría ser la confirmación que introduce la "regresión" (como puede ver, _ssize_tse basaría en __SIZE_TYPE__(que es esencialmente size_tde acuerdo con el mensaje de confirmación). Probablemente terminaría siendo unsigned longcuando Cygwin sea de 64 bits, segúnesteyeste), así que apuesto a que no podrá reproducir el problema con Cygwin de 32 bits (incluso en Windows de 64 bits, claro está). Tal vez valga la pena mencionar queun compromiso aún más tempranoprobablemente una vez lo "arregló". Por eso lo llamo "regresión".
Actualización 2: y sí, tengo razón:
Quizás ahora debería obtener Visual Studio y comprobarlo _write()(y tal vez write()) un poco...
PD: No deberías encontrarte con el error de "valor extraño" si estás haciendo una prueba de solo lectura en el "último bloque + 1" como _read()devolvería 0, a diferencia de _write()cuál devolvería -1y establecería errnoen ENOSPC, cuando "intenta leer al final del archivo" (la unidad).
Respuesta2
El valor decimal 4294967295, en hexadecimal FFFFFFFF, se representa simplemente -1como un entero de 32 bits sin signo. Este es un código de error API común y no tiene otro significado. La utilidad badblockses muy básica, escrita hace décadas por Linus Torvalds, que solo escribe datos y los vuelve a leer.
Recuento de sectores incorregibles denota la cantidad de sectores defectuosos que el firmware del disco ha detectado pero que no ha podido reubicar en sectores buenos porque estos sectores no se pudieron leer. El firmware ha desistido de intentar reubicar estos sectores.
Entonces, hay 459 sectores no recuperables que el firmware ha detectado pero no puede reasignar.
El disco se encuentra sin duda en una fase terminal.
Si desea salvar el disco y no le importa su contenido, puede intentar formatearlo, reescribir y renovar todos los sectores buenos, mientras marca como malos los sectores que el firmware no puede tocar. Aquí es preferible una utilidad del fabricante. Se debe evitar Cygwin, ya que sus utilidades de Linux no garantizan una buena integración con Windows.
El Página de soporte de DiamondMax sugiere la utilidad de disco bastante reciente Versión del Asistente de disco: 23.0.17160, que quizás podría hacer el formato profundo. Esta es una utilidad de Windows.
Si el disco en cuestión es el disco del sistema de Windows, es posible que necesite ejecutar la utilidad desde un disco de arranque de Windows PE o desde un disco de rescate como Win10PEx64 modificado por Bob.Omb. También podrías usar un Disco de recuperación basado en Windows PE de arranque como Alquiler de BootCD PE. En caso de necesidad, puede intentar formatear el disco desde un arranque en vivo de Linux.
(Adición para la publicación reescrita)
La respuesta anterior aparentemente fue aceptada por el autor dos años antes de que se escribiera y se reemplazara el disco. Esta parte trata sobre el nuevo disco.
El nuevo disco está en perfecto estado y sin defectos, pero badblocks muestra un mensaje de error.
Badblocks es una utilidad antigua, escrita por Linus Torvalds, quizás incluso antes de que existiera Linux. Todo lo que hace es crear un archivo temporal, escribir en él hasta encontrar el final del espacio y luego volver a leer los datos. Como prueba de disco es pésimo y sólo "prueba" el espacio libre en el disco.
Además, se ejecuta en Cygwin y ni siquiera en Windows, por lo que su comprensión de los códigos de error devueltos por Windows es extremadamente dudosa. Ni siquiera puede informar el código de error real, sino que siempre informa un -1
código de error. No hay forma de imaginar cuál sería el resultado si Cygwin intentara traducir un código de error de la API de Windows a lo que imagina que es el código de error equivalente de Linux.
Francamente, ignoraría este error espurio como si no tuviera sentido, probablemente simplemente debido a un malentendido del código de retorno "no más espacio", mal entendido por badblocks o Cygwin. Los datos devueltos por el firmware SMART son mucho más concretos.
En el post Equivalente a badblocks en Windows o DOS Se ofrecieron varias sugerencias, todas ellas mucho mejores que badblocks, ya que prueban todo el disco y no sólo el espacio libre.
Una buena alternativa es chkdsk /r, que utiliza la utilidad de Windows.
chkdsk
para localizar sectores defectuosos y recuperar información legible, analizando errores del disco físico en todo el disco.