Manual de uso del SSD en Linux

[Viper_Scull]

Hola.

Como veo que no está muy extendido el uso de los nuevos discos SSDs en Linux por el foro, voy a crear esta pequeña guía sobre configuración, uso y precauciones que hay que tomar cuando vayamos a usar este tipo de dispositivos en Linux. No soy ningún gurú, así que toda la inforamación la he ido sacando de muchas páginas y muchos foros, y de ir peleandome con ello, lo que haré es juntar aquí todo lo que he ido recopilando y aprendiendo, y lo que considero personalmente que es lo que mejor va.

Para más información sobre SSDs en general, controladoras disponibles, descripción técnica, étc, consultad este hilo

Comentar que los SSDs han sido el mayor avance en el rendimiento del Pc desde hace muchisimo tiempo, y aunque ahora tengan un precio algo alto (sobre los 2€ por GB), espermos que dentro de un tiempo no muy lejano tenga unos precios más acordes y todo el mundo pueda tener acceso a una de estas maravillas. Es sin ningún lugar a duda la mejor compra informática que he hecho.


COMPARACION CON DISCOS TRADICIONALES (controladora SF-1200)

·Tiempo de acceso irrisorio (0,1 msg vs 8-10msg en HDDs)
·Velocidad de escritura/lectura sostenida (270MB/Sg vs 120MB/sg en HDDs)
·Hasta 60.000 IOPS (operaciones de entrada/salida por segundo) teóricos. Cifremoslo en el mundo real en 25.000 vs las 130 de un HDD.
·Consumo (2W vs 10W de un HDD)

Actualización Mayo 2011: Actualmente ya tenemos discos con controladora SF2000 como el OCZ Vertex 3 o el Corsair FS3. Estos discos tienen tasas de lectura y escritura de más de 500 MB/sg (usando conexión SATA 3, en SATA 2 usa el límite de esta, unos 280 MB/sg). TIenen mucha menor degradación de rendimiento ya que las controladoras han mejorado.
Ahora mismo mi elección sería un Corsair FS3 (con un máx. de 85K IOPS), que se pondrá a la venta a principios de Junio.


¿QUÉ SISTEMA DE FICHEROS ELEGIR?

Actualmente hay dos preparados para los SSDs: Ext4 y Btrfs.
Mientras el primero es estable desde hace ya unas cuantas versiones del kernel y está en un buen estado de madurez, el segundo, prometedor donde los haya está aún en versión desarrollo.
Además Ext4 tiene un rendimiento superior actualmente, así que este será nuestro sistema elegido para las particiones en un SSD.


PRECAUCIONES A TENER EN CUENTA

Si ya habeis leido el hilo de referencia (que deberia ser obligado), veremos que esta tecnología presenta un par de problemas:

-Pérdida de rendimiento con el tiempo al ir escribiendo en las celdas (No demasiado apreciable para un uso normal con las controladoras Sandforce).
Tenemos un mecanismo para paliar esto llamado TRIM. Para usarlo debemos asegurarnos que estamos usando un kernel no anterior a la version 2.6.33. Además de ellos tendremos que montar las particiones ext4 con la opción discard

-Vida de ciclos de escritura no tan elevado como en discos mecánicos (Actualmente se estima unos 10 años de uso)
Para evitar escrituras innecesarias en el disco vamos a montar las particiones con la opción noatime.
Además sabemos que Ext4 es un sistema que realiza journaling, así que otra medida que podemos tener para evitar estas escrituras es deshabilitar el journaling a la hora de crear las particiones. Esto lo dejo a elección de cada uno, yo particularmente lo tengo deshabilitado, pero se puede habilitar en cualquier momento.
Las cachés de los navegadores, los temporales, logs del sistema, etc, también realizan muchas escrituras, así que nos encargaremos de que en vez de escribir al SSD escriban a la RAM.
La partición Swap la realizaremos en un disco mecánico, aunque para la gente que disponoga de 4GB de RAM y no quiera hibernar, mi recomendación es nisiquiera tenerla.
También podemos poner /home en una partición de un HDD para que no vaya escribiendo los archivos de configuración en el SSD.

Como veis, no son realmente problemas por los que preocuparse mucho (dentro de 10 años seguramente hemos cambiado varias veces de disco duro), pero para alargar la vida de las celdas y mantener el rendimiento lo más alto posible vamos más adelante a explicar detalladamente los pasos a seguir para realizar todo lo que hemos comentado de una forma teórica.

Para aprovechar el máximo rendimiento es conveniente seleccionar en la BIOS el modo AHCI para las unidades SATA. Y se recomienda colocar el SSD en el primer puerto SATA de la placa base.


PARTICIONADO DEL DISCO

Este es un punto importante. Para sacar todo el rendimiento posible a un disco de estado sólido las particiones tienen que estar alineadas. Esto a grandes rasgos significa que una particion debe comenzar en un punto de la memoria que sea múltiplo del tamaño de borrado de celdas que tenga el SSD (dependiendo de uno u otro podría ser 128, 256, 512KB...)

Si queremos usar una única partición que contenga /, /home, etc, con una distribución como Ubuntu 10.10, bastará entonces con meter el cd y que Ubuntu use el disco entero, ya que teóricamente lo alineará bien. Así que para una única partición podeis saltaros este paso.

Pero si vamos a tener varias particiones, o a deshabilitar el journal, o a instalar junto a Windows en el mismo disco necesitaremos realizar las particiones a mano y para esto vamos a usar fdisk.

Se podría usar tanto GPT, como MBR, pero vamos a seguir por ahora con el tradicional MBR que es el que más compatibilidad tiene. Con las futuras sustituas de las BIOS, EFI, considero mejor usar GPT.

Arrancamos con un livecd, o liveusb, de por ejemplo Ubuntu o alguna otra distribución. O si queremos podemos usar la instalacion que tengamos previa en otro disco duro para hacer el particionado del SSD. Es conveniente colocarlo en la primera toma SATA que tengamos de la placa, es decir, SATA 0, con lo que debería ser reconocido como /dev/sda. En caso de tener otro nombre, utilizar el que corresponda.

Ejecutaremos en consola el siguiente comando:

fdisk -S 32 -H 32 /dev/sda

con el que le estamos indicando que la tabla de particiones tenga 32 sectors y 32 heads con lo que usará un tamaño de cilindro de 1024 bytes.

Ahora vamos a crear las particiones, en el ejemplo voy a crear 2, una para / y otra para /home para ver como se hace más de una partición, pero puede ser recomendable poner /home en un disco mecánico para evitar aún todas las escrituras que van realizando los programas en sus carpetas (descarga de correo, lista de canciones, etc, etc), con lo cual sólo habría que hacer la partición de /, lo que nos dejaría más particiones librer por si queremos instalar alguna otra distribución. Posteriormente comentaré el caso en el que queramos particionar con Windows también. / tendrá un tamaño de 20GB y el resto serán para /home

Command (m for help): o
Building a new DOS disklabel with disk identifier 0x8cb3d286.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

The number of cylinders for this disk is set to 15711.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-15711, default 1): 2
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711):+20G

......

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711):

.....

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Bien ya hemos creado las 2 particiones, ahora vamos a darles el formato con nuestro sistema de ficheros elegidos: Ext4.

Aqui también vamos a alinear los sistemas de ficheros, para los cuales usaremos según el disco que tengamos diferentes valores del stripe. Os pongo la informacion que saqué de un artículo referente a esto mismo:

Intel SSDs with an erase block size of 128 (or 512 KiB -- Intel isn't quite straightforward with this, see the comments section for a discussion on the subject - if anyone from Intel is reading this, help us out! ) that are not part of a software RAID:
-E stride=32,stripe-width=32

OCZ Vertex SSDs with an erase block size of 512 KiB that are not part of a software RAID:
-E stride=128,stripe-width=128

Normal hard drives that are not part of a software RAID
trust the defaults

Any software RAID:
-E stride=raid chunk size / file system block size,stripe-width=raid chunk size x number of data bearing disks

Así que al estar haciendo las pruebas en un OCZ Vertex 2 vamos a crear los formatos con el valor que nos recomiendan:

mkfs.ext4 -E stride=128,stripe-width=128 -O ^has_journal /dev/sda1
mkfs.ext4 -E stride=128,stripe-width=128 -O ^has_journal /dev/sda2

Fijaros en el parámetro -O ^has_journal. Con esto he indicado que la partición ext4 no tengo journaling. si alguno de vosotros quiere que sí lo tenga bastaría con quitar ese parámetro a la hora de darle formato a las particiones.

El sistema de ficheros ext4 reserva una cantidad porcentual al tamaño de la partición. Esto hace que nos quite mucha cantidad en particiones grandes. Nosotros podemos variar ese porcentaje a nuestro gusto, pero la regla para que esto se haga debe ser la siguiente:

·La partición no es una partición de sistema
·Si la partición es una partición de sistema, debe tener más de 50GB

Así que en este caso vamos únicamente a cambiar el porcentaje reservado de la partición de /home, ya que la otra es de sistema y no supera los 50GB. Vamos a darle un valor del 1% a la memoria reservada que es un valor totalmente seguro (IMPORTANTE: este comando es sólo válido para particiones ext3 y ext4)

sudo tune2fs -m 1 /dev/sda2

CONFIGURACIÓN DEL SISTEMA OPERATIVO

Una vez instalado el sistema que hayamos elegido vamos a proceder a tomar todas las precauciones a la hora de evitar escrituras innecesarias y repetidas, y habilitar la posibilidad de TRIM (todo lo que comenté anteriormente).


Montaje de particiones

En primer lugar vamos a tocar el archivo /etc/fstab, dónde se le dice al sistema los puntos de montaje y las opciones de montaje. Así deberían quedar las líneas referente al montaje a las particiones (si alguno le pone alguna opción más que la incluya).

/dev/sda1 / ext4 defaults,errors=remount-ro,noatime,discard 0 1
/dev/sda2 /home ext4 defaults,noatime,discard 0 1

Es conveniente como ya comenté antes que los logs, y temporales no escriban constantemente en el disco duro, así que vamos a crear unos tmpfs para que se escriban en la RAM. Esto se añadirá también al archivo /etc/fstab

none /tmp tmpfs nodev,nosuid,noatime,size=2000M,mode=1777 0 0
tmpfs /var/tmp tmpfs noexec,defaults,noatime 0 0
tmpfs /var/log tmpfs defaults,noatime 0 0

Le he dado un tamaño a /tmp de 2GB teniendo 4GB, pero podeis dejarlo sin ese tamaño y que se vaya ajustando sólo. Lo puse para que no llegara a saturarme la RAM en caso de creciera mucho, porque suelo compilar en el temporal para no gastar el disco duro, y un kernel ocupa bastante.
Realmente si no compilais kernel en RAM podeis quitar esa opcion o dejar simplente 1GB, que es como lo tenia al principio. Esa tamaño que indicamos no va a ser el que esté ocupado, simplemtene pone un límite para ocupar en RAM, lo que se vaya ocupando es lo que se irá marcando en el consumo.

Para el que no disponga de mucha RAM y/o quiera tener particion SWAP. Tendrá que realizar una partición en un HDD tradicional para evitar posibles escrituras innecesarias. Normalmente en el instalador de la distribución se pedirá cual es la partición swap y se encargará de montarla en fstab el sistema. Pero por si ocurre cualquier cosa la línea debería quedar algo como esto:
/dev/sdb5 swap swap defaults 0 0




Actualización del sistema

Al actualizar el sistema mediante apt-get, yum, pacman...etc. ésta baja los archivos al disco y luego los instala. Si por ejemplo tenemos programas como chromium-dev o paquetes de un git que se actualizan cada poco tiempo, o por ejemplo en actualizaciones como KDE entera que son más de 400 megas y no queremos que se vayan descargando al SSD podemos cambiar la ruta de descarga de estos paquetes.

En Arch Linux por ejemplo en /etc/pacman.conf tenemos un campo que es CacheDir. En principio está comentado. Debajo escribiremos CacheDir = ruta_del_directorio. Y a partir de ese momento se descargarán en él (debeis crear el directorio si no existe).
En distros derivadas de Debian tendremos que modificar el archivo /etc/apt/apt.conf (crear si no existe) y modificar/escribir esta línea dir::cache::archives “ruta”;

Las 2 opciones que hay son las siguientes:
Si crees que no vas a necesitar paquetes antiguos para volver a antiguas versiones y te da igual borrar los paquetes descargados una vez instalados podemos para el que tenga suficiente ram poner como directorio de bajada /tmp. De tal modo al reiniciar esos paquetes no estarán (recordar que hemos montado /tmp en RAM)
Si quieres mantener un poco de seguridad para posible downgrades a antiguas versiones lo mejor será poner una carpeta de un disco HDD.


Navegadores

Vamos a mover también a la RAM las cachés de los navegadores, que realizan muchas escrituras, con lo cual no sólo ganaremos eso, sino que el navegador irá más rápido.

Para Chromium:
Añadir a /etc/fstab:

cache-chromium /home/user/.cache/chromium tmpfs defaults,noatime,mode=1777 0 0

Donde user es nuestro usuario. Después eliminar el archivo de caché que nos haya creado en nuestra /home y volverlo a crear:

rm -R /home/user/.cache/chromium
mkdir /home/user/.cache/chromium

Para Opera ahora lo mismo:
Añadir a /etc/fstab:

cache-opera /home/user/.opera/cache tmpfs defaults,noatime,mode=1777 0 0

y después eliminar el archivo de caché que nos haya creado en nuestra /home y volverlo a crear:

rm -R /home/user/.opera/cache
mkdir /home/user/.opera/cache

Para Firefox:
Escribir about:config en la barra de navegacion.
Buscar el campo browser.cache.disk.enable y ponerle como valor false
Busca el campo browser.cache.memory.enable y ponerle como valor true
Busca el campo browser.cache.memory.max_entry_size y darle el valor en KB que querías asignarles como máximo. Para los que no tengais problemas de RAM poned -1


Scheduler

Por último vamos a tratar del tema del scheduler de I/O. Nomalmente los discos tradicionales usan el scheduler CFQ, mientrás que para las memorias flash y discos de estado solido se recomiendas los schedulers noop y deadline. Sin embargo en los test más recientes que he visto (Agosto 2011) para escenarios normales los schedulers noop y deadline dan mejores resultados incluso en los HDDs, así que será uno de estos el que usaré para todos los discos. He probado los 2 y yo me quedo con noop.

Para ajustar el scheduler que queramos hay 2 opciones:
-Cargarlo una vez arrancado el sistema, que sería hacerlo mediante el archivo /etc/rc.local (en arch y algunas otras distros), /etc/init.d/rc.local (en Debian y derivadas) añadiendo:

echo noop > /sys/block/sda/queue/scheduler

-O meterlo como opcion de arranque del kernel. Editando ya sea el /boot/grub/menu.lst para grub o el /etc/default/grub para grub2. El parámetro a añadir es:

elevator=noop

Hay una tercera opción que es la que uso yo ya que compilo mis propios kernels. Es compilar el kernel con el scheduler noop como predefinido, así todos los discos arrancan con este scheduler sin tener que tocar nada.


INSTALACIÓN JUNTO CON WINDOWS
Bueno no difiere mucho, lo único que tendríamos que hacer es a la hora de hacer fdisk que la primera partición sea la de windows. Y seguir el mismo procedimiento, de empezar en el sector 2, y luego ir añadiendo los tamaños con +xG (donde x es el número de gigas), la última partición basta con darle al Enter para que coja todo el resto, o si queremos dejar algo libre simplemente indicar el tamaño para la partición. Después instalaríamos Windows en la primera partición (Windows 7 crearía 2, una para boot y una para sistema), y más tarde instalar Linux en las otras particiones con lo que grub se instalaría en el MBR como siempre.


Bueno hasta aquí hemos llegado. Con las novedades iré actualizando esto, al igual que cuando btrfs esté maduro y estable, ya que viene preparado para SSD con una opción directa. Espero que todas las horas que me he pasado con esto durante meses por ahí os ayuden con ete tema, y os invito a que deis el salto cualitativo a este tipo de dispositivos si podeis. Ya os pondré una captura y video de arranque del sistema, carga de aplicaciones y demás cuando pueda.

Un saludo.

[Viper_Scull]

Bueno despueés de comentar los pasos generales para el particionado, instalación y configuración del sistema operativo voy a pasar a explicar los pasos para recuperar el estado original del disco (y recuperar así la velocidad con la que vino de fábrica), y la actualización del firmware de los dicos OCZ basados en controladora Sandforce, como es el caso del mío (Vertex 2).


RECUPERAR EL ESTADO ORIGINAL DEL DISPOSITIVO
Esta guía es de los foros de OCZ, la voy a traducir a español y ponerla aquí para tener todo en un mismo post.

Vamos a asegurarnos de que tenemos en la BIOS el disco en modo AHCI. Y que tenemos conectado el disco antes de arrancar el pc.

En primer lugar descargaremos la distribución Partition Magic y o bien lo quemaremos en un CD, o bien haremos un Live-USB (por ejemplo con unetbootin).
Nos aseguraremos que en la BIOS arranquemos a través de CD o de USB.

Una vez arrancado Partition Magic, abriremos el programa Erase Disk. (System tools -> Erase disk)



Seleccionaremos Internal: Secure Erase command writes zeros to entire data area y continuamos



Seleccionamos el disco a "resetear" y pulsamos OK



Nos saldrá una ventana pidiendo un password, y deberá aparecer escrito NULL. Dejad NULL como password y pulsad ok.



Después pulsad YES. Saldrá una cajita diciendo que se ha ejecutado que sólo durará unos segundos.

Y listo ya tenemos el disco como nos vino de fábrica (un formateo no es suficiente para conseguir esto).

Importante: si cuando vais a hacer el Erase os dice que no puede porque el disco esta en modo Frozen. No apagueis el Pc, dejad el live cd corriendo. Abrid la caja y desconectad el cable de alimentación del SSD durante 1 minuto, volvedlo a conectar y repetid los pasos de arriba.



COMO ACTUALIZAR EL FIRMWARE EN DISCOS CON CONTROLADORA SANDFORCE SF-1200

Para actualizar el firmware necesitamos que el sistema operativo no esté en el SSD, así que o bien tendremos otro disco con un sistema Linux, o ya que este no suele ser el caso cuando tenemos SSD, que por eso ha costao lo suyo, lo haremos desde un LiveCd o LiveUSB de una distribución Linux de 32 bits que nos permita tener conexion a internet (obligatorio y si es por cable mejor).

Una vez arrancada la distribución descargaremos la utilidad necesaria para esta tarea:

Versión zip
Version tar
Una vez extraído el contenido y dados permisos de ejecución pasaremos a actualizar los discos.

Haciendolo todo en consola serían estos pasos:

wget http://www.ocztechnologyforum.com/staff/tony/OCZ_SF_updates/fwupd_beta1.zip
unzip fwupd_beta1.zip
sudo chmod +x fwupd
sudo ./fwupd /dev/sd?

y se encargará de descargar y actualizar el firmware de todos los SSDs que tengamos a la última versión.

CUTRE VIDEO

Os adjunto el enlace a un cutre-video que hice con el móvil grabando el arranque del sistema. Es una mierda ya que tengo que estar sujetando con una mano y parece que tengo parkinson porque tengo que estar levantando la cabeza para ver donde doy y moviendo ahi el raton, pero bueno os podeis hacer una ideilla del rendimiento.

http://www.youtube.com/watch?v=ElgZ8SoJUs0

[bart0n]

[hcakal]

Sip, en efecto, buen manual. A ver si lo hacen fijo o bien añaden una reseña al post de HOWTOs!

Yo es que no tengo nada de SSDs pero está bien conocer algo más, lo único que se le parece al SSD que tengo yo es un CFtoIDE xD

[iqpi]

Un manual excelente, enhorabuena, a ver si puedo pillar un SSD algún día xD

[Desactualizado]

Estupenda aportación ,muchas gracias.

El día que baje sustancialmente el precio de estos dispositivos me actualizaré.

[nilla]

Excelente manual, ya me preocupa un poco menos comprar un SSD

[viejozorro]

Estupenda aportación Viper. Cuando me pille un SSD tendré que consultar este hilo.

Y por cierto, esto necesita chincheta YA!

[Suprimido]

Actualización del sistema

Al actualizar el sistema mediante apt-get, yum, pacman...etc. ésta baja los archivos al disco y luego los instala. Si por ejemplo tenemos programas como chromium-dev o paquetes de un git que se actualizan cada poco tiempo, o por ejemplo en actualizaciones como KDE entera que son más de 400 megas y no queremos que se vayan descargando al SSD podemos cambiar la ruta de descarga de estos paquetes.

En Arch Linux por ejemplo en /etc/pacman.conf tenemos un campo que es CacheDir. En principio está comentado (dejémoslo así por si queremos volver a poner el default). Debajo escribiremos CacheDir = ruta_del_directorio. Y a partir de ese momento se descargarán en él (debeis crear el directorio si no existe).
En distros derivadas de Debian aún no lo he mirado porque no tengo instalado ninguna, en cuanto lo sepa lo pongo. Si alguno me lo quiere decir bienvenido sea.

Las 2 opciones que hay son las siguientes:
Si crees que no vas a necesitar paquetes antiguos para volver a antiguas versiones y te da igual borrar los paquetes descargados una vez instalados podemos para el que tenga suficiente ram poner como directorio de bajada /tmp. De tal modo al reiniciar esos paquetes no estarán.
Si quieres mantener un poco de seguridad lo mejor será poner una carpeta de un disco HDD.

En Ubuntu (Debian, etc) hay que poner lo siguiente en el archivo /etc/apt/apt.conf (si no esta hay que crearlo):

dir::cache::archives “ruta”;

Yo tengo la ruta de un HDD, y descarga allí todo lo que vayamos a instalar!

Un saludo

[Viper_Scull]

Gracias Suprimido.

Anotado en el post principal.