Los primeros problemas se detectaron hace algo más de un mes con una unidad Samsung SSD 840 EVO que al actualizar al firmware EXT0DB6Q empezó a fallar en Linux.
El falló se dio a conocer en un bug de Ubuntu que todavía hoy sigue abierto. Tal y como comenta el primer usuario en informar de ello, después de actualizar el firmware de una unidad Samsung SSD 840 EVO a la versión EXT0DB6Q, el comando ‘fstream’ ha dejado de funcionar. Además hay muchos errores del sistema de archivos y «sectores defectuosos». El problema lo provoca el firmware de Samsung pero lo reporto como un fallo porque en Windows, TRIM funciona con normalidad después de la actualización. Adjunto una imagen de un usuario que ha experimentado el mismo problema. Si ejecutas el comando ‘sudo fstrim /’ en la consola, lo tienes. Si añades el comando en rc.local, el arranque se ve comprometido.
El problema se ha podido reproducir por una gran cantidad de usuarios que usan versiones muy diferentes del kernel y el fallo viene dado por la función TRIM, una técnica que permite al sistema operativo informar a la unidad SSD de los bloques de datos que no están en uso para que esta pueda repartir los datos por toda la unidad, lo cual minimiza el número de lecturas/escrituras y aumenta su vida útil.
Algunos usuarios han intentando contactar con los responsables del firmware afectado sin demasiado éxito. Otros usuarios han afirmado que sufren el mismo problema con el modelo 850 PRO. Finalmente, en una de las últimas revisiones del kernel se han incluido los modelos 8xx en una lista negra para no activar TRIM en dichas unidades.
Así pues, si dispones de un disco de estado sólido de Samsung para su uso en Linux, no actualices el firmware hasta que solucionen el problema. Si ya lo has hecho, deberás usar un kernel muy reciente (a partir de Linux 4.0.5) donde se deshabilitarán algunas características de TRIM para los modelos afectados.
gracias por la informacion!
Pero utilizar el ultimo kernel no soluciona el otro problema de ralentizaciones con el tiempo (mas lento a mayor antiguedad de los datos) verdad?. Que opinas de lo que se menciona en este blog http://yktoo.com/en/blog/post/255
Usas la solucion que proponen? Gracias
Creo que este fallo se solucionó en alguna de las últimas versiones del kernel, pero no encuentro el pull request.
Si se usa una versión vieja del kernel y el firmware ya está actualizado, la opción que propone este tipo parece funcionarle aunque ya advierte que se use bajo riesgo el propio usuario.
En cualquier caso, no usaría este modelo actualizado en ninguna versión del kernel ni bajo ningún parche para almacenar datos relevantes.
En mi búsqueda de respuestas he encontrado este otro artículo
http://www.pcper.com/reviews/Storage/Samsung-Magician-46-and-840-EVO-EXT0DB6Q-Firmware-Review-Finally-Fixed
en el que se dice que el propio firmware, en su última versión EXT0DB6Q, ya se ocupa de refrescar los datos más antiguos, sin necesidad de la aplicación de window$ Samsung Magician. Con lo cual entiendo que si uno usa Linux, el nuevo algoritmo sigue trabajando igual, o me equivoco? Por ese lado el problema de disminución de velocidad cuanto mas antiguos los datos estaría «resuelto» en Linux, y no haría falta ejecutar el programa que se describe en el blog que enlacé en mi anterior comentario.
O igual me estoy liando. Aún quedaría el tema de fstrim, que yo pensaba colocar en rc.local (como aconsejan en https://sites.google.com/site/easylinuxtipsproject/ssd)
Entiendo que puedo hacerlo, siempre que mi kernel sea posterior a 4.0.5.
En tu artículo comentas «se deshabilitarán algunas características de TRIM», pero no entiendo si se realizará TRIM o no, o cómo se traduce esto en la realidad. ¿Se puede decir que mi SSD será más lento/»vivirá» menos si lo uso en Linux en estas circunstancias que en window$?
Efectivamente, viendo el percal en el SSD no guardaré datos, únicamente el sistema operativo.
Gracias un saludo
Carlos, gracias por esos enlaces. La verdad es que tengo un 840 EVO evidentemente con Linux y al no haber actualizado el firmware desde que salió esta noticia, no he tenido problemas y no he estado informado de la evolución del asunto.
No encuentro el pull request que trata la solución del problema en el kernel, por lo que no sé hasta qué punto se sigue realizando TRIM. Pero sí, que Linux desactive TRIM para este modelo es un problema para la durabilidad de la unidad. Aunque en principio el rendimiento no debería verse afectado.
Un saludo.