Ir al contenido
Shiba87

Discos de estado sólido (SSD) en GNU/Linux. Optimización y consideraciones generales

Recommended Posts

ObcXZRh.png


Durante los últimos años, los discos de estado sólido han sido la apuesta de futuro en almacenamiento informático. Aunque inicialmente los desorbitados precios, la escasa durabilidad y escasa capacidad de los SSD hacían que estos dispositivos estuvieran únicamente al alcance de entusiastas con el suficiente dinero en las bolsillos. Pero tras unos años en el mercado las cosas han cambiado y a día de hoy empiezan a ser una alternativa tentadora para casi cualquier usuario.

Los discos de estado sólido son increíblemente rápidos y están carentes de cualquier pieza mecánica móvil, lo que los hace silenciosos, soportan mucho mejor las vibraciones y los golpes y no se ven afectados (o casi) por problemas tales como la fragmentación del sistema de ficheros. Aunque evidentemente, hay que tener en cuenta una serie de consideraciones para sacarles el máximo partido y prolongar su vida útil tanto como sea posible.



Sistemas de archivos

En GNU/Linux contamos con una gran variedad de sistemas de ficheros diferentes y en este caso no iba a ser menos.
Ext4 sería la opción más estable y trabajada y, por tanto, la más recomendable a la hora de formatear un SSD para GNU/Linux.
No obstante Btrfs aunque más reciente y aún en desarrollo es una interesante alternativa, así como el recién creado f2fs, aunque este último tendría mayor utilidad en sistemas móviles y portátiles que en equipos de escritorio y servidores.

La lista de sistemas de ficheros con soporte Trim sería la siguiente:

  • ext4 (recomendado)
  • btrfs
  • f2fs
  • xfs
  • jfs





Trim ¿Qué es eso?

TRIM permite que el sistema operativo informe a una unidad SSD sobre qué bloques de datos no están en uso y pueden ser borrados.
Esto tiene especial importancia en el caso de los discos de estado sólido, pues las memorias flash de tipo NAND que componen los SSD no pueden sobrescribir datos existentes. Antes de escribir nuevos datos sobre los existentes, es necesario borrarlos primero. A este problema se suma el hecho de que la unidad mínima de borrado es un bloque, mientras que la unidad de escritura mínima es una página (un bloque son 64 páginas).
 

DtC2sBh.png


Esto significa que conforme pasa el tiempo, el disco SSD se irá, en cierto modo, fragmentando internamente (no de la misma manera que los discos duros tradicionales) quedando páginas con bloques vacíos, lo que hará que en algún momento que aún cuando haya espacio libre en el SSD, no quedarán páginas vacías en las que escribir. Esto hará que disminuya el rendimiento debido a que para escribir datos nuevos habrá que reagrupar los bloques que están dispersos, copiándolos a una memoria intermedia, borrándolos y reuniéndolos todos de nuevo en una misma página.

Cuando se borra un archivo, lo que hace el sistema operativo es marcarlo como borrado dentro del sistema de archivos, pero no se lo comunica al disco de estado sólido. Es por eso que TRIM, que como ya hemos dicho se encarga de informar al disco de estado sólido qué está borrado, nos ayuda a evitar los problemas antes mencionados.


Comprobando que tenemos soporte TRIM

Para ello haremos uso de la herramienta hdparm.
 

hdparm -I /dev/sdX | grep TRIM

 
Siendo sdX es la unidad que corresponde a nuestro SSD

La respuesta será clara, en caso de estar soportado nos lo dirá y en caso contrario no habrá respuesta.


Diferentes métodos para hacer uso de TRIM

Hay diversas maneras de llevar a cabo el proceso a tener en cuenta.


Manualmente:

Mediante el comando fstrim, paquete que tendremos que instalar previamente, podemos realizar la acción en cualquier momento
 

fstrim -v /

Como se puede ver en color rojo, debemos indicar el punto de montaje de nuestro SSD, que en el ejemplo es la raíz. Si no es así, simplemente ponemos el que crresponda
 
Evidentemente, esto supone tener que estar ejecutando una y otra vez el comando cada vez que trabajemos con nuestro SSD



Configurando el fstab

Mediante la opción discard, podemos configurar nuestro disco SSD para que haga uso de TRIM a través del fichero /etc/fstab
Basta con añadir esta opción a las que aparecen en la línea correspondiente al disco de estado sólido:
 

/dev/sda / ext4 discard,errors=remount-ro 0 1


Otras opciones que podemos añadir son

  • nodiratime (No actualizar tiempo de acceso a directorios)
  • noatime (No actualizar tiempo de acceso a ficheros)

/dev/sda / ext4 discard,noatime,nodiratime,errors=remount-ro 0 1


Esta solución es sencilla, rápida y efectiva, pero tiene un gran inconveniente y es que no sólo se hará uso de TRIM sino que se llevará a cabo el proceso todas y cada una de las veces que se trabaje con el disco duro, lo que significa mayor trabajo, que a su vez implica menor rendimiento.



Programando la ejecución de fstrim

Mucho más efectivo que el método anterior, la ejecución programada de fstrim nos permite disfrutar de los beneficios de éste, sin apenas efectos en lo que a rendimiento se refiere.

Podemos hacerlo de distintas maneras, pudiendo elegir cualquiera de ellas.


Mediante Cron

Porque si hablamos de tareas programadas no podemos olvidarnos de Cron.

Creamos el archivo /etc/cron.daily/trim para que la ejecución de fstrim se realice diariamente que contenga lo siguiente
 

#!/bin/sh
fstrim -v /

Como se puede ver en color rojo, debemos indicar el punto de montaje de nuestro SSD, que en el ejemplo es la raíz. Si no es así, simplemente ponemos el que crresponda
 
 
Y le damos permisos de ejecución

chmod +x /etc/cron.daily/trim

Mediante Systemd

Porque este novedoso sistema de arranque vale para hacer muchísimas cosas, así que si nos encontramos usándolo no vamos a desaprovecharlo.

Creamos el archivo correspondiente al servicio que queremos crear en /lib/systemd/system/fstrim.service cuyo contenido será el siguiente
 



[unit]
Description=Trim free cells on the SSD
After=local-fs.target

[service]
ExecStart=/sbin/fstrim /
Type=oneshot

[install]
WantedBy=multi-user.target


Como se puede ver en color rojo, debemos indicar el punto de montaje de nuestro SSD, que en el ejemplo es la raíz. Si no es así, simplemente ponemos el que crresponda

Ya sólo queda habilitar el servicio con systemctl
 

systemctl enable fstrim
systemctl status fstrim

NOTA Podemos valernos de los archivos de ejemplos provistos por Systemd para esta tarea:



cp /usr/share/doc/util-linux/examples/fstrim.{service,timer} /etc/systemd/system

E igualmente habilitarlos después con systemctl

systemctl enable fstrim.timer

Particiones encriptadas

Existe un caso especial y es cuando las particiones están encriptadas. En este caso tendremos que hacer unas cuantas cosas más.

En primer lugar añadiremos dos opciones al grub modificando el archivo de configuración /etc/default/grub

A las opciones que figuran entre comillas en la línea



GRUB_CMDLINE_LINUX=""

añadiremos lo siguiente

GRUB_CMDLINE_LINUX="allow-discards root_trim=yes"

Guardamos los cambios y actualizamos el grub mediante el comando

update-grub

Ahora vamos a editar el archivo de configuración /etc/crypttab

y al igual que hicimos antes con el fstab, añadimos la opción discard a la línea que corresponda a nuestra unidad SSD
 

#<target name> <source device> <key file> <options>
sda1_crypt /dev/sda1 none luks,discard


Así mismo, debemos habilitar TRIM en la configuración de LVM a través del archivo /etc/lvm/lvm.conf mediante la opción issue_discards dentro de "devices {}"
 

# [...]
devices {
# [...]
issue_discards = 1
# [...]
}
# [...]



Tras cambiar las opciones de los sistemas de ficheros, también es conveniente actualizar las imágenes de arranque initramfs
 

update-initramfs -u -k all





Montar temporales en la memoria RAM (Aconsejado)

Como ya dijimos en el tema TMPFS, montando los temporales en RAM, es una buena idea hacer uso de la memoria RAM para tareas repetitivas y archivos que se van a usar de manera recurrente para no hacer trabajar al disco de estado sólido más de la cuenta y alargar así su vida útil.

El proceso es bastante sencillo, sólo tendremos que definir las opciones de montaje de los temporales en el archivo /etc/fstab y tmpfs hará el resto
 

tmpfs      /tmp          tmpfs      defaults,noatime,nodiratime,mode=1777    0    0





Almacenar logs en la memoria RAM (Desaconsejado)

Este proceso es casi idéntico al anterior, sólo que en lugar de definir los directorios correspondientes a los temporales en el archivo /etc/fstab, lo haremos con los directorios que almacena los logs del sistema

tmpfs      /var/log        tmpfs      defaults        0    0

Es una opción que, si bien hay que nombrarla, no es nada aconsejable, pues la memoria RAM es volátil y los datos desaparecen cuando apagamos, reiniciamos o suspendemos el equipo. Esto hace que para diagnosticar cualquier problema esta opción resulte contraproducente.





IO scheduler (Planificador)

Por defecto, la mayoría de sistemas GNU/Linux utilizan CFQ como planificar de entrada/salida
Sin embargo, para discos de estado sólido existen otras opciones que resultan más aconsejables como pueden ser:

  • noop (recomendado)
  • deadline

De manera general, si el SSD es el único medio de almacenamiento del equipo, configuraremos Grub para que lo ajuste mediante la opción elevator que añadiremos modificando la configuración del archivo /etc/default/grub

A las opciones que figuran entre comillas en la línea

GRUB_CMDLINE_LINUX=""

añadiremos lo siguiente

GRUB_CMDLINE_LINUX="elevator=noop"

Guardamos los cambios y actualizamos el grub mediante el comando

update-grub

Para otros casos en los que existen diferentes medios de almacenamiento, comúnmente SSD y disco duro convencional, no podremos valernos del grub porque cada unidad necesitará unos parámetros distintos para funcionar correctamente.

Forma rudimentaria

Podemos asignar el planificador al vuelo de manera simple y sobre la marcha.
 

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

Siendo sdX la unidad SSD

Para hacer este cambio permanente, tendremos que asignar el planificador elegido a la unidad correspondiente en el archivo de configuración /etc/sysfs.conf
 

echo "block/sdX/queue/scheduler = noop" >> /etc/sysfs.conf



Asignar planificador Mediante udev

Antes que nada debemos asegurarnos que el kernel es consciente de que utilizamos una unidad SSD



for f in /sys/block/sd?/queue/rotational; do printf "$f is "; cat $f; done

El valor "0" nos indica que esa unidad es, efectivamente, un disco de estado sólido
 

/sys/block/sda/queue/rotational is 0
/sys/block/sdb/queue/rotational is 1


Siendo así, creamos el archivo /etc/udev/rules.d/60-ssd-scheduler.rules en el cual asignaremos un planificador a cada una de las unidades en función del tipo que sean, teniendo en cuenta que para discos de estado sólido lo recomendable será CFQ y para los SSD será NOOP o de contar con un kernel que lo incluya, BFQ.
 

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}==" 0", ATTR{queue/scheduler}="noop"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"




Limitando al máximo el uso de la Swap

A día de hoy, podemos perfectamente prescindir de la memoria de intercambio y con un SSD no sólo es así por la velocidad y prestaciones de éste, sino porque no nos interesa que se esté haciendo uso del disco como swap porque estaríamos reduciendo su vida útil.

Para esto vamos a editar el archivo /etc/sysctl.conf centrándonos en tres cosas

  • Reducir el porcentaje de uso swap/ram al 1%
  • Disminuir valor de cache de bloques de datos de 100 a 50
  • Modificar la frecuencia de acceso al disco de 500 a 1500

Lo que se conseguiría añadiendo al final de dicho archivo de configuración las siguientes opciones

vm.swappiness=1
vm.vfs_cache_pressure=50
vm.dirty_writeback_centisecs=1500





Reducir el número de chequeos de los sistemas de ficheros (Gracias WiLLiTo)

Como sabemos, cada cierto número de veces que iniciamos el sistema se realiza de forma automática un chequeo de los sistemas de ficheros para asegurar que todo sigue como es debido.
Como lo que buscamos es limitar el uso del disco SSD, sería una buena idea hacer que estos chequeos ocurran menos a menudo modificando el intervalo de tiempo o el número de reinicios que transcurren entre uno y otro.

Mediante tune2fs podemos modificar este valor y también hacer otras muchas cosas, apuntando siempre a la partición sobre la que queremos actuar
 

tune2fs -c 80 /dev/sda1 (cada 80 reinicios)
tune2fs -i 2m /dev/sda1 (cada 2 meses)
tune2fs -i 2w /dev/sda3 (cada 2 semanas)
tune2fs -i 2d /dev/sda1 (cada 2 dias)
tune2fs -l /dev/sdb1 (ver registro completo de la partición)
tune2fs -l /dev/sda3 | grep ‘Last checked’ (ver fecha del último escaneo)
tune2fs -l /dev/sda3 | grep -i check (veces que se fuerza el chequeo)
tune2fs -i 0 /dev/sda3 (desactivar chequeo)

Y también algunas opciones útiles que podemos usar

tune2fs -l /dev/sda3 | grep -i ‘mount count’ (saber cuantos reinicios faltan hasta el próximo chequeo)
e2fsck -fpD /dev/sda1 (para optimizar la partición)





Test simple de velocidad

Porque no podemos trastear sin contar con una manera, aunque sea muy simple de ver cómo nuestras acciones afectan al rendimiento del disco :P
Para eso volveremos a hacer uso de hdparm
 

hdparm -Tt /dev/sdX

 
Siendo, como siempre, sdX es la unidad que corresponde a nuestro SSD





Fuentes

https://wiki.debian.org/SSDOptimization
https://wiki.archlinux.org/index.php/Solid_State_Drives
http://blog.neutrino.es/es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

Compartir este post


Enlace al post
Compartir en otros sitios

También conviene  aumentar el numero máximo de montajes antes de realizar un checkeo del sistema de archivos (normalmente a 10 o 15) a 25 o 30 montajes o más. Es algo así como

 

# tune2fs -c 80 /dev/sda1 (cada 80 reinicios)
# tune2fs -i 2m /dev/sda1 (cada 2 meses)
# tune2fs -i 2w /dev/hda3 (cada 2 semanas)
# tune2fs -i 2d /dev/sda1 (cada 2 dias)
# tune2fs -l /dev/sdb1 (ver registro completo de la partición)
# tune2fs -l /dev/hda3 | grep ‘Last checked’ (ver fecha del último escaneo)
# tune2fs -l /dev/hda3 | grep -i check (veces que se fuerza el chequeo)
# tune2fs -i 0 /dev/hda3 (desactivar chequeo)
# showfsck (saber cuantas reiniciadas faltan hasta el proximo chequeo)
# tune2fs -l /dev/hda3 | grep -i ‘mount count’ (lo mismo que el anterior)
# e2fsck -fpD /dev/sda1 (para optimizar la partición)

 

Editado por WiLLiTo

Compartir este post


Enlace al post
Compartir en otros sitios

Tal y como están las cosas y teniendo en cuenta el uso que le doy a mi ordenador, me parece que no me merece para nada la pena. Como dice @@Rohlling, cuando la tecnología esté más depurada y los precios más equilibrados, entonces será el momento de empezar a usarlos para sustituir a los HDD

Compartir este post


Enlace al post
Compartir en otros sitios

hola por suerte ya hace tiempo que estoy utilizando ssd ocz agility 3 60gb 2.5

 

 

este es el resultado de Test simple de velocidad de mi ssd

 

 

hdparm -Tt /dev/sdb1

/dev/sdb1:
 Timing cached reads:   7876 MB in  2.00 seconds = 3945.43 MB/sec
 Timing buffered disk reads: 536 MB in  3.01 seconds = 178.22 MB/sec

 

saludos

Compartir este post


Enlace al post
Compartir en otros sitios

¿Seguro que está en /dev/sdb? Porque me parecen valores más propios de HDD que de SSD :sweat:

 hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   22226 MB in  2.00 seconds = 11124.70 MB/sec
 Timing buffered disk reads: 1534 MB in  3.00 seconds = 511.16 MB/sec

Compartir este post


Enlace al post
Compartir en otros sitios

Mis 3 cositas (ningún ssd):

/dev/sdb:
 Timing cached reads:   8648 MB in  2.00 seconds = 4325.04 MB/sec
 Timing buffered disk reads: 364 MB in  3.01 seconds = 120.75 MB/sec

/dev/sda:
 Timing cached reads:   8760 MB in  2.00 seconds = 4381.07 MB/sec
 Timing buffered disk reads: 500 MB in  3.00 seconds = 166.54 MB/sec

/dev/sdc:
 Timing cached reads:   8688 MB in  2.00 seconds = 4345.24 MB/sec
 Timing buffered disk reads: 414 MB in  3.01 seconds = 137.71 MB/sec

sdc es un WD Velociraptor de 600GB (donde tengo win)

sda es un WD Green 2TB (donde tengo ... :silba: )

sdb es un WD Blue 500GB (donde tengo linux)

 

Para leer el Green el mejor....

 

Perdón offtopic :)

Compartir este post


Enlace al post
Compartir en otros sitios

df
  

/home/shiba# df

S.ficheros                                             1K-bloques    Usados Disponibles Uso% Montado en

 

rootfs                                                    8125880   7212352      494100  94% /

udev                                                        10240         0       10240   0% /dev

tmpfs                                                     1630636       592     1630044   1% /run

tmpfs                                                     4076584       492     4076092   1% /dev/shm

tmpfs                                                     4076584       192     4076392   1% /sys/fs/cgroup

tmpfs                                                        5120         0        5120   0% /run/lock

tmpfs                                                      102400         4      102396   1% /run/user

tmpfs                                                     3145728        60     3145668   1% /tmp

tmpfs                                                     4076584         0     4076584   0% /var/tmp

/dev/sda5                                               206293688  86490476   109317460  45% /home

/dev/sda6                                               265382776 117463132   134432348  47% /media/Datos

Compartir este post


Enlace al post
Compartir en otros sitios
df
  

/home/shiba# df

S.ficheros                                             1K-bloques    Usados Disponibles Uso% Montado en

 

rootfs                                                    8125880   7212352      494100  94% /

udev                                                        10240         0       10240   0% /dev

tmpfs                                                     1630636       592     1630044   1% /run

tmpfs                                                     4076584       492     4076092   1% /dev/shm

tmpfs                                                     4076584       192     4076392   1% /sys/fs/cgroup

tmpfs                                                        5120         0        5120   0% /run/lock

tmpfs                                                      102400         4      102396   1% /run/user

tmpfs                                                     3145728        60     3145668   1% /tmp

tmpfs                                                     4076584         0     4076584   0% /var/tmp

/dev/sda5                                               206293688  86490476   109317460  45% /home

/dev/sda6                                               265382776 117463132   134432348  47% /media/Datos

 

Gracias, esto es lo que pasa por dejar de usar linux por unos meses :icon_ouch:

Compartir este post


Enlace al post
Compartir en otros sitios

hola a todos

 

ya tengo el /etc/fstab modificado

 

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sdb1 during installation
UUID=a38741d2-1dbe-4b57-83cd-3b4352c46ee7 /               ext4    discard,noatime,nodiratime,errors=remount-ro 0       1
# swap was on /dev/sdb5 during installation
UUID=2a0c25ac-fcc1-490a-ba06-300e5ee7f4aa none            swap    sw              0       0
UUID=244654ba-6a74-43bb-a9dd-3295e37f1604     /media/DESPENSA   ext4   errors=remount-ro 0 1

 

 

y en la ejecución de fstrim Mediante Systemd

[unit]
Description=Trim free cells on the SSD
After=local-fs.target

[service]
ExecStart=/sbin/fstrim /dev/sdb1
Type=oneshot

[install]
WantedBy=multi-user.target


al final cuando voy a habilitarlo devuelbe esto

systemctl status fstrim
systemctl: no se encontró la orden

 

 

 

donde me equivoco?

 

 

saludos

Compartir este post


Enlace al post
Compartir en otros sitios

Dos cosas

 

Primera

¿Seguro que estás utilizando systemd?¿Tienes todos los paquetes instalados?

 

Segunda

¿Estás ejecutando Systemctl como usuario o como root? :P

 

P.D. En despensa es mejor que pongas el pass a 2

 

UUID=244654ba-6a74-43bb-a9dd-3295e37f1604     /media/DESPENSA   ext4   errors=remount-ro 0 2

Compartir este post


Enlace al post
Compartir en otros sitios

Estoy viendo para instalar Debian en un SSD de 20GB que vino en mi notebook casi misteriosamente

Me gustaría saber si voy a notar mayor velocidad, porque aunque tenga la raíz instalada en el SSD voy a tener que poner mi /home en el disco duro común

También quisiera saber si durante la instalación hay que hacer algo especial al instalar en un SSD porque por lo que veo todo lo que está en el post se hace después

Compartir este post


Enlace al post
Compartir en otros sitios

Sí. No necesariamente tienes por qué dejar el /home en el disco duro convencional, podrías dejar /home y raíz en el SSD, dejándolos para lo esencial y los archivos de configuración de tu usuario/s y los archivos personales y actividades propias de tu actual home relegarlas al disco duro común. En ese sentido es más cuestión de cómo se organiza cada uno :P

 

Algo importantísimo que hay que hacer en la instalación para que la instalación de Debian en el disco SSD sea satisfactoria y no de problemas en el futuro es, durante el proceso de particionado, elegir correctamente la partición del disco SSD donde se va a instalar la raiz del sistema :jojojo: :jojojo:

 

Y nada, de resto ya lo has leído más arriba, no hay misterio ;)

Compartir este post


Enlace al post
Compartir en otros sitios

Registra una cuenta o conéctate para comentar

Debes ser un miembro de la comunidad para dejar un comentario

Crear una cuenta

Regístrate en nuestra comunidad. ¡Es fácil!

Registrar una cuenta nueva

Iniciar Sesión

¿Ya tienes cuenta? Conéctate aquí.

Iniciar Sesión

×