Actualizar

Question

No sé cómo forzar el fsck usando la solución que estás probando, pero puedo sugerir una solución alternativa:

Utilice tune2fsy limite el valor a remontajes muy bajos y marcas de tiempo muy bajas.

# To see current settings
sudo tune2fs -l /dev/sda4
# To alter it
sudo tune2fs -c 1 -i 1d /dev/sda4

Esto forzará el cheque cada 1 reinicio o cada 1 día desde el último cheque, lo que suceda antes.

Verificar INTELIGENTE

Como han dicho otros, esto es sólo una curita para los problemas de HW. A veces el disco duro se está muriendo, otras veces es un problema de hardware no relacionado (realice una prueba de memoria), en otras ocasiones es solo un cable SATA suelto (desconéctelo y conéctelo nuevamente desde ambos extremos, si eso no lo soluciona, pruebe con otro cable). .

Tenga cuidado, en el peor de los casos, la fuente de alimentación no funciona correctamente y está dañando el resto del hardware (en tal caso, reemplazar el disco duro solo solucionará el problema temporalmente porque con el tiempo la fuente de alimentación dañará el nuevo disco duro). Verifique que los voltajes estén dentro de niveles aceptables.

Publicar el resultado de smart:

sudo smartctl -a /dev/sda

Puede ayudar a diagnosticar lo que podría estar pasando.

Actualizar

Tampoco sé por qué no puedes ejecutar fsck a través de tune2fs.

Pero vi tu SMART. Según él, su disco está envejeciendo, pero parece estar en buen estado.

El problema puede estar en otra parte, como en el cable SATA.

Si no puede hacer que fsck funcione, entonces todo lo que puedo sugerir es iniciar desde un liveUsb y ejecutar el comando manualmente.

Actualización 2

OK, publicaste los mensajes dmseg.Tenemos información contradictoria procedente de SMART & OS., así que lo escribiré en detalle.

Bloques malos

SMART dice que sus unidades tienen bloques defectuosos. Esto es normal en cualquier SSD a medida que envejece.y la unidad reasignará los datos en bloques de repuesto. Una vez que se agota el repuesto, es necesario reemplazar la unidad.

SMART dice que la cantidad de bloques defectuosos está dentro de lo "normal": Los atributos más importantes que se pueden ver aquí son Reallocated_Sector_Cty Runtime_Bad_Block.

Dice que detectó 311 bloques defectuosos y reasignó 311 a repuesto. Esto es bueno. Si hubo 311 bloques defectuosos pero solo 310 reasignaciones, significa que los datos de uno de los bloques se perdieron.

Lo importante es el valor "normalizado" (038). Así te dice el fabricante lo que considera normal.

Un valor donde 100 significa perfecto y 0 significa realmente malo. Ahora mismo es 38, que es decir "esto se está poniendo mal"; pero el fabricante dice que está bien siempre que ese valor esté por encima de 010 (el UMBRAL).

Aquí tenemos nuestra primera información contradictoria: Used_Rsvd_Blk_Cnt_Totdice que la reserva no ha sido tocada en absoluto, a pesar de tener bloques defectuosos. No cuadra.

Pero no me sorprendería que el firmware simplemente no rastree este valor a pesar de informarlo, por lo que lo ignoraremos por ahora.

Nivelación de desgaste

Este es el atributo más problemático de leer. Wear_Leveling_Countdice que es 001. Normalmente un valor de 1 significa que su unidad está muerta y debe ser reemplazada lo antes posible.

Significa que se le acabaron los bloques de repuesto. Pero ha habido errores de firmware en los que este atributo se informa al revés, y un valor de 1 significa que la unidad tiene un estado de funcionamiento del 99 %.

Usando uncalculadora de TBWInserté su número de LBA escritos + tamaño de sector 512 y obtuve que su unidad tiene 77,43 TiB escritos. Según Google, su modelo debería tener 150 TBW, por lo quedeberíaseguir siendo viable.

Me temo que la mejor solución aquí es abrir un cuadro de Windows y ejecutarCrystalDiskInfoque tiene en cuenta estos errores de firmware (utilizando una base de datos interna) y le informará una evaluación de salud muy precisa.

Dado que su inteligencia dice que SMART overall-health self-assessment test result: PASSEDme inclino a creer que quiere decir 99%, en lugar de 1%.

Pero si me equivoco podemos detenernos aquí, hay que reemplazar el disco.

Problemas de cables/Problemas de placa base

Los errores en dmesg de Linux básicamente dicen que intentó leer un sector y obtuvo datos incorrectos.

El kernel incluso dice que intentó leer el sector 235602696 dos veces y obtuvo datos diferentes:

28 00 0e 0b 03 08 00 002000
28 00 0e 0b 03 08 00 000800.

Si el disco dice que no hay errores pero el sistema operativo dice que sí; luego los datos se corrompieron durante el tránsito. Normalmente esto indica:

El cable SATA está flojo
El cable SATA está dañado
El cable de alimentación está flojo
El cable de alimentación está dañado
Fallo del bus de la placa base
Fallo de la fuente de alimentación
Fallo de RAM

Pero aquí es donde tenemosnuestra segunda fuente de información contradictoria: UDMA_CRC_Error_Countes 0.

Esto significa que el disco nunca detectó un solo error causado por un cable defectuoso/suelto o un bus de la placa base defectuoso.

Esto es muy improbable. SMART dice que el disco está bien, los comandos que llegan desde el sistema operativo al disco nunca se corrompen por un cableado defectuoso; sin embargo, el sistema operativo leyó el mismo sector dos veces y obtuvo un byte diferente.

Lo único que se me ocurre que haría esto posible es si tienes mala RAM.O un problema de cable extremadamente improbable en el que todos los datos que entran en el disco nunca se corrompen, pero los datos que salen sí se corrompen.

Curso de acción

Mi instinto me dice que el disco está defectuoso. Pero:

Haga una copia de seguridad de todos los datos en otro disco. En una ejecución LiveUSB (y una unidad USB externa lo suficientemente grande):

sudo apt install zstd

# To backup
sudo zstd -16v < /dev/sda > /media/external_disk/backup_file.zst

# To restore (don't do that on step 1, see step 5)
sudo zstdcat -v /media/external_disk/backup_file.zst > /dev/sda

Haga una copia de seguridad de los datos nuevamente, pero esta vez con solo una copia normal de los archivos (si el disco muere, es mucho más fácil recuperarse de una copia de seguridad simple que intentar montar en bucle una imagen zstd comprimida de un disco y leer los archivos de ella).
Reinicie y ejecute una prueba de memoria para descartar errores de RAM
Apague, abra la carcasa y desconecte y vuelva a enchufar los cables SATA y de alimentación (a la unidad). Comprueba que no estén dañados. Posiblemente reemplazarlos.
Inicie nuevamente en la unidad LiveUSB y realice un borrado seguro del disco. Si hay algún problema con su unidad, tal vez esto la restablezca a una condición de funcionamiento (o tal vez resulte en el último comando que se ejecuta si el disco no se puede salvar). Esto debería tomar varios minutos:

sudo blkdiscard -s /dev/sda

Si todo ha ido bien hasta ahora, restaure su copia de seguridad con el sudo zstdcatcomando del paso 1.

Si el disco aún tiene problemas y memtest tuvo éxito, entonces personalmente consideraría que el disco está defectuoso.

No podemos ignorar que un valor de 038 Reallocated_Sector_Ctsignifica que las cosas se están poniendo mal, a pesar de que el fabricante diga que todavía no está "tan mal".

¡Ah! Importante: Si en algún momento dejaste el disco apagado por más de 3 meses; Este escenario es bastante posible. A pesar de la creencia popular, las celdas NAND pueden perder su capacidad de almacenamiento si se dejan sin alimentación durante demasiado tiempo ("demasiado tiempo" puede oscilar entre 7 días y 7 años; pero el caso más común es 3 meses). Especialmente si son viejos.

Si esto le sucedió a usted, simplemente realice los pasos anteriores: haga una copia de seguridad de los datos, borre el disco de forma segura y restaure la copia de seguridad.

Buena suerte.

Answer 1

No sé cómo forzar el fsck usando la solución que estás probando, pero puedo sugerir una solución alternativa:

Utilice tune2fsy limite el valor a remontajes muy bajos y marcas de tiempo muy bajas.

# To see current settings
sudo tune2fs -l /dev/sda4
# To alter it
sudo tune2fs -c 1 -i 1d /dev/sda4

Esto forzará el cheque cada 1 reinicio o cada 1 día desde el último cheque, lo que suceda antes.

Verificar INTELIGENTE

Como han dicho otros, esto es sólo una curita para los problemas de HW. A veces el disco duro se está muriendo, otras veces es un problema de hardware no relacionado (realice una prueba de memoria), en otras ocasiones es solo un cable SATA suelto (desconéctelo y conéctelo nuevamente desde ambos extremos, si eso no lo soluciona, pruebe con otro cable). .

Tenga cuidado, en el peor de los casos, la fuente de alimentación no funciona correctamente y está dañando el resto del hardware (en tal caso, reemplazar el disco duro solo solucionará el problema temporalmente porque con el tiempo la fuente de alimentación dañará el nuevo disco duro). Verifique que los voltajes estén dentro de niveles aceptables.

Publicar el resultado de smart:

sudo smartctl -a /dev/sda

Puede ayudar a diagnosticar lo que podría estar pasando.

Actualizar

Tampoco sé por qué no puedes ejecutar fsck a través de tune2fs.

Pero vi tu SMART. Según él, su disco está envejeciendo, pero parece estar en buen estado.

El problema puede estar en otra parte, como en el cable SATA.

Si no puede hacer que fsck funcione, entonces todo lo que puedo sugerir es iniciar desde un liveUsb y ejecutar el comando manualmente.

Actualización 2

OK, publicaste los mensajes dmseg.Tenemos información contradictoria procedente de SMART & OS., así que lo escribiré en detalle.

Bloques malos

SMART dice que sus unidades tienen bloques defectuosos. Esto es normal en cualquier SSD a medida que envejece.y la unidad reasignará los datos en bloques de repuesto. Una vez que se agota el repuesto, es necesario reemplazar la unidad.

SMART dice que la cantidad de bloques defectuosos está dentro de lo "normal": Los atributos más importantes que se pueden ver aquí son Reallocated_Sector_Cty Runtime_Bad_Block.

Dice que detectó 311 bloques defectuosos y reasignó 311 a repuesto. Esto es bueno. Si hubo 311 bloques defectuosos pero solo 310 reasignaciones, significa que los datos de uno de los bloques se perdieron.

Lo importante es el valor "normalizado" (038). Así te dice el fabricante lo que considera normal.

Un valor donde 100 significa perfecto y 0 significa realmente malo. Ahora mismo es 38, que es decir "esto se está poniendo mal"; pero el fabricante dice que está bien siempre que ese valor esté por encima de 010 (el UMBRAL).

Aquí tenemos nuestra primera información contradictoria: Used_Rsvd_Blk_Cnt_Totdice que la reserva no ha sido tocada en absoluto, a pesar de tener bloques defectuosos. No cuadra.

Pero no me sorprendería que el firmware simplemente no rastree este valor a pesar de informarlo, por lo que lo ignoraremos por ahora.

Nivelación de desgaste

Este es el atributo más problemático de leer. Wear_Leveling_Countdice que es 001. Normalmente un valor de 1 significa que su unidad está muerta y debe ser reemplazada lo antes posible.

Significa que se le acabaron los bloques de repuesto. Pero ha habido errores de firmware en los que este atributo se informa al revés, y un valor de 1 significa que la unidad tiene un estado de funcionamiento del 99 %.

Usando uncalculadora de TBWInserté su número de LBA escritos + tamaño de sector 512 y obtuve que su unidad tiene 77,43 TiB escritos. Según Google, su modelo debería tener 150 TBW, por lo quedeberíaseguir siendo viable.

Me temo que la mejor solución aquí es abrir un cuadro de Windows y ejecutarCrystalDiskInfoque tiene en cuenta estos errores de firmware (utilizando una base de datos interna) y le informará una evaluación de salud muy precisa.

Dado que su inteligencia dice que SMART overall-health self-assessment test result: PASSEDme inclino a creer que quiere decir 99%, en lugar de 1%.

Pero si me equivoco podemos detenernos aquí, hay que reemplazar el disco.

Problemas de cables/Problemas de placa base

Los errores en dmesg de Linux básicamente dicen que intentó leer un sector y obtuvo datos incorrectos.

El kernel incluso dice que intentó leer el sector 235602696 dos veces y obtuvo datos diferentes:

28 00 0e 0b 03 08 00 002000
28 00 0e 0b 03 08 00 000800.

Si el disco dice que no hay errores pero el sistema operativo dice que sí; luego los datos se corrompieron durante el tránsito. Normalmente esto indica:

El cable SATA está flojo
El cable SATA está dañado
El cable de alimentación está flojo
El cable de alimentación está dañado
Fallo del bus de la placa base
Fallo de la fuente de alimentación
Fallo de RAM

Pero aquí es donde tenemosnuestra segunda fuente de información contradictoria: UDMA_CRC_Error_Countes 0.

Esto significa que el disco nunca detectó un solo error causado por un cable defectuoso/suelto o un bus de la placa base defectuoso.

Esto es muy improbable. SMART dice que el disco está bien, los comandos que llegan desde el sistema operativo al disco nunca se corrompen por un cableado defectuoso; sin embargo, el sistema operativo leyó el mismo sector dos veces y obtuvo un byte diferente.

Lo único que se me ocurre que haría esto posible es si tienes mala RAM.O un problema de cable extremadamente improbable en el que todos los datos que entran en el disco nunca se corrompen, pero los datos que salen sí se corrompen.

Curso de acción

Mi instinto me dice que el disco está defectuoso. Pero:

Haga una copia de seguridad de todos los datos en otro disco. En una ejecución LiveUSB (y una unidad USB externa lo suficientemente grande):

sudo apt install zstd

# To backup
sudo zstd -16v < /dev/sda > /media/external_disk/backup_file.zst

# To restore (don't do that on step 1, see step 5)
sudo zstdcat -v /media/external_disk/backup_file.zst > /dev/sda

Haga una copia de seguridad de los datos nuevamente, pero esta vez con solo una copia normal de los archivos (si el disco muere, es mucho más fácil recuperarse de una copia de seguridad simple que intentar montar en bucle una imagen zstd comprimida de un disco y leer los archivos de ella).
Reinicie y ejecute una prueba de memoria para descartar errores de RAM
Apague, abra la carcasa y desconecte y vuelva a enchufar los cables SATA y de alimentación (a la unidad). Comprueba que no estén dañados. Posiblemente reemplazarlos.
Inicie nuevamente en la unidad LiveUSB y realice un borrado seguro del disco. Si hay algún problema con su unidad, tal vez esto la restablezca a una condición de funcionamiento (o tal vez resulte en el último comando que se ejecuta si el disco no se puede salvar). Esto debería tomar varios minutos:

sudo blkdiscard -s /dev/sda

Si todo ha ido bien hasta ahora, restaure su copia de seguridad con el sudo zstdcatcomando del paso 1.

Si el disco aún tiene problemas y memtest tuvo éxito, entonces personalmente consideraría que el disco está defectuoso.

No podemos ignorar que un valor de 038 Reallocated_Sector_Ctsignifica que las cosas se están poniendo mal, a pesar de que el fabricante diga que todavía no está "tan mal".

¡Ah! Importante: Si en algún momento dejaste el disco apagado por más de 3 meses; Este escenario es bastante posible. A pesar de la creencia popular, las celdas NAND pueden perder su capacidad de almacenamiento si se dejan sin alimentación durante demasiado tiempo ("demasiado tiempo" puede oscilar entre 7 días y 7 años; pero el caso más común es 3 meses). Especialmente si son viejos.

Si esto le sucedió a usted, simplemente realice los pasos anteriores: haga una copia de seguridad de los datos, borre el disco de forma segura y restaure la copia de seguridad.

Buena suerte.

Actualizar

Respuesta1

Verificar INTELIGENTE

Actualizar

Actualización 2

Bloques malos

Nivelación de desgaste

Problemas de cables/Problemas de placa base

Curso de acción

información relacionada