Los discos de estado sólido (Solid State Drives o SSD) han supuesto una revolución en las prestaciones de los PCs en los últimos años. De hecho es, con diferencia, la mejor inversión para mejorar el rendimiento de cualquier PC, existente o nuevo. Sin embargo, aunque pueden utilizarse como cualquier disco duro convencional, hay algunas características que requieren una atención especial. Sobre todo ahora que aun estamos familiarizándonos con la tecnología y los sistemas se van adaptando a las particularidades de estos dispositivos.

Recientemente he escrito algunos artículos en las listas de correo de guifi.net respecto al uso de estos discos duros en servidores basados en Linux y he pensado en recopilar y comentar aquí algunos enlaces interesantes que he encontrado en el proceso de investigación.

Durabilidad

“Los discos SSD se degradan rápidamente y tienen una vida útil más corta que los discos mecánicos” — leyenda urbana ;-)

La mayoría de las afirmaciones relativas a la poca vida útil de los discos duros SSD estan basadas en la (mala) lectura de partes de artículos técnicos. La realidad es que un SSD ha de ser, en general, más longevo que un disco mecánico. Y sobre todo más estable y predecible.

Un disco SSD no es como una memoria USB con un puerto SATA. Eso es como decir que un disco duro magnético es como un floppy con una caja rígida y un conector SATA. Aunque la base es la misma (la memoria flash) el sistema de acceso (controladora) no tiene nada que ver con el de una memoria USB. Y es una de las principales razones de los precios de los SSD.

A nivel corporativo ya se utilizan discos SSD y con muy buenos resultados. Por ejemplo, toda la infraestructura de Anandtech.

Para comprender bien la base de la leyenda de la durabilidad es necesario evaluar y entender que los firmware de estos discos ya tienen en cuenta el desgaste y toman acciones preventivas para mitigar el efecto. El resultado es que los discos SSD deben durar, en general, más que los discos mecánicos.

En este artículo se habla de un caso concreto con la tecnología de 20 nm que es la más pequeña (y más vulnerable) a este problema. Os pego una parte del artículo:

Doing the math on the 240GB capacity gives us 2083 full drive writes over the life of the drive, or about 5.7 years of useful life if you write 240GB of data to the NAND every day. Even if your workload has a write amplification factor of 10x, you’re still talking about 24GB of writes per day for nearly 6 years.

Y eso en un caso extremo de funcionamiento 24/7. Para un PC que usemos un par de horas al dia el disco quedará obsoleto antes de presentar problemas de durabilidad. Incluso un PC de trabajo (pongamos 10 horas al dia, 5 dias a la semana) superamos con facilidad la década.

Para acabar de convencer a los indecisos en este foro de xtreme systems estan recopilando duraciones reales de discos SSD desde que se compran hasta que mueren (literalmente) y bajo condiciones muy duras (24/7 con muchas escrituras en algunos casos).

TRIM

Una de las diferencias fundamentales de un disco SSD vs un disco mecánico convencional es que en el primero no se pueden sobreescribir directamente los datos, primero hay que “borrar” el espacio a utilizar. En un disco magnético clasico las cabezas lectoras pueden leer (captando las diferencias de campo magnético) o escribir (generando un campo magnético suficientemente intenso para cambiar el del disco que tienen debajo). En un disco SSD leer una celda es simplemente ver si hay una cierta resistencia (el voltaje cambia). Pero para escribir es necesario dejar la celda en un estado de borrado. De manera que hay tres operacions: leer, escribir, borrar. No puedes escribir si no borras antes. Sin embargo todos los sistemas de ficheros hasta hace poco han supuesto que escribir permite sobreescribir, no que escribir implique antes borrar. Así que podemos encontrar en un disco SSD que escribir un fichero es doblemente costoso porque, además de la escritura, primero hay que borrar.

De ahí que se detecta, en discos SSD antiguos o con sistemas que no soportan TRIM, que el rendimiento va decayendo con el tiempo (a medida que se va utilizando todo el disco) con independencia de si hay o no espacio “libre” de disco.

Para mitigar este efecto los fabricantes han desarrollado una comunicación entre el sistema operativo y la controladora de disco que permite a esta última marcar zonas del disco como libres y poder borrarlas antes de escribirlas. Esto permite mantener el rendimiento de los discos SSD independientemente de las escrituras.

El TRIM podemos hacerlo de dos maneras diferentes: sobre la marcha (online) o en diferido (offline). Parece que lo deseable sería hacerlo online pero eso implica hacer los borrados de ficheros más lentos. Existe una herramienta para hacerlo offline (no es necesario desmontar el disco) que puede utilizarse de manera programada en horas de poca carga.

Os paso dos enlaces interesantes al respecto:

https://patrick-nagel.net/blog/archives/337

http://www.unix.com/man-page/all/8/fstrim/

Yo por mi parte en un servidor cuyo disco principal es SSD tengo programado un trim offline por las noches.

RAID / mdadm

El principal problema actualmente con el uso de trim es al añadir capas de abstracción en el sistema de ficheros por encima del dispositivo. En en caso de linux las capas más habituales son RAID (mdadm) y LVM.

He estado investigando si a nivel del mdadm y del kernel de linux se había introducido el cambio y parece que sí, aunque con un kernel bastante nuevo.

La propuesta de cambio la he encontrado en la lista de desarrollo del kernel, con un patch de Shaohua Li que tiene la bendición del desarrollador del md de Linux Neil Brown. Parece que el cambio se ha introducido en kernel 3.7 tal como aparece en el changelog:

MD: TRIM support for linear (commit), raid 0 (commit), raid 1 (commit), raid 10 (commit), RAID 5 (commit)

Por tanto, en principio, parece que debe funcionar (con un kernel bastante nuevo).