Mantenimiento del SDD corectamente en Archlinux.

Hace un par de días instale Arch por que no me iba systemd bien en Gentoo y he encontrado un blog donde explican como ahorranos escrituras.

Bueno los pasos que hay que seguir son escasos y dependemos de la memoria RAM para ahorranos escrituras.

Lo primero es añadir noatime en nuestro fstab

# nano /etc/fstab

UUID=09564f6c-3dd5-4101-a5de-6075b1c4abaf   /            btrfs        rw,noatime,ssd,compress=lzo,space_cache   0 0


Si usamos discard hay que quitarlo ya que fstrim.timer no es recomendable, y aparte discard hace mas lento el SDD.
Todo esto esta en la Wiki de arch


Lo segundo con systemd seria activar fstrim.timer

sudo systemctl enable fstrim.timer

Si no nos parece suficiente frecuencia, podemos editar el archivo para que haga TRIM diariamente

$ sudo nano /usr/lib/systemd/system/fstrim.timer
------------------------------------------------
[Unit]
Description=Discard unused blocks daily
Documentation=man:fstrim

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

[Install]
WantedBy=multi-user.target


Por defecto, Arch usa CFQ como planificador de E/S [3]. Podemos cambiar este por NOOP o Deadline. Ambos mejoran el rendimiento de las SSDs. Normalmente, NOOP es la opción más recomendable.

$ cat /sys/block/sdX/queue/scheduler  # X es la letra de nuestra SSD
noop deadline [cfq]  # aparece entre corchetes


En caso de querer cambiarlo, se puede hacer sin reiniciar con:

$ sudo echo noop > /sys/block/sdX/queue/scheduler  # X → letra de la SSD


Una vez confirmado el cambio:

$ cat /sys/block/sdX/queue/scheduler  # X es la letra de nuestra SSD
[noop] deadline cfq


y estando seguros de nuestra elección, hay que volverlo permanente (en caso contrario, se perderá al reiniciar). Con una simple regla de udev bastará.

$ sudo nano /etc/udev/rules.d/60-schedulers.rules
-------------------------------------------------
# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",ATTR{queue/scheduler}="noop"



Opcional: Limitar el número de chequeos de los sistemas de archivos (yo no lo he hecho ya que no utilizo ext4)

A fin de garantizar la integridad de los datos, el sistema operativo realiza un chequeo a todo sistema de archivos que acumula x número de montajes desde su última revisión. Por defecto suele ser a los treinta, pero dado que lo que queremos es minimizar el desgaste de la SSD, deberíamos ampliar este valor para estirar el tiempo entre prueba y prueba.

$ sudo tune2fs -c 60 /dev/sda2  # 60 montajes
$ sudo tune2fs -i 2[d|w|m] /dev/sda2  # días|semanas|meses, 2d → 2 días
$ sudo tune2fs -l /dev/sda2  # ver registro del sistema de archivos
$ sudo tune2fs -l /dev/sda2 | grep "Last checked"  # fecha último chequeo
$ sudo tune2fs -l /dev/sda2 | grep "t count"  # nº de montajes máximo y
actual


Ahora montamos tmpfs en memoria ram recomendable 8 Gib de memoria ram.

Podemos hacerlo de tres métodos.

1. Método que utilice el 50% de nuestra memoria ram

tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0


2. Método eligiendo el tamaño que queremos

tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777,size=2G 0 0


En size= ponemos el numero gigas que queramos.

3. Método utilizando espacio que queramos

tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777,size=25% 0 0


Nota: esta memoria no es asignada en régimen de exclusividad. tmpfs sólo toma la memoria que necesita en el momento, quedando el resto disponible para otras tareas.

Ahora montamos los perfiles de navegadores en RAM y nos ahorramos varios megas de escritura y lectura diaria.

AUR cuenta con varios paquetes para automatizar este proceso, como es el caso de profile-sync-daemon.

yaourt -S profile-sync-daemon

Configuración

/etc/psd.conf contiene la configuración de profile-sync-daemon.

Definimos la lista de usuarios cuyos perfiles queremos que gestione psd. Para ello, editamos la variable USERS con sus nombres.

# Example
# USERS="facade debbie"
USERS="mi_usuario otro_usuario"


Donde mi_usuario y otro_usuario son los usuarios elegidos. Hemos de apuntar al menos un nombre.

Opcionalmente, podemos descomentar BROWSERS y detallar los navegadores que queremos que psd maneje. En mi caso:

# Uncomment and select which browsers to manage if you wish
# Otherwise all available/supported browsers will be managed
# which is NOT recommended if users have many browser profiles
BROWSERS="firefox google-chrome-beta"


Si no editamos esto, psd buscará e intentará llevar todos los navegadores que soporta (la lista se encuentra en la configuración): trabajo extra inútil.

En VOLATILE se puede indicar a psd una ruta de destino distinta para los perfiles.

# Suggested locations based on distro defaults:
#   Arch Linux/Chakra, Fedora, and Gentoo leave this commented out
#   Debian 6 and below use a setting of "/dev/shm"
#   Debian 7+  use a setting of "/run/shm"
VOLATILE="/tmp"


Además, si tenemos una versión del kernel Linux igual o superior a la 3.18.0, podemos descomentar la variable USE_OVERLAYFS para usar overlayfs, lo que supone un nuevo incremento en la velocidad de sincronización y un menor consumo de RAM.

# Uncomment to use overlayfs instead of a full copy to reduce the memory costs
# and to improve sync/unsync operations. This feature requires a Linux kernel
# version >=3.18.0 to work. For more, see the overlayfs kernel docs.
USE_OVERLAYFS="yes"


Revisamos la configuración la configuración

profile-sync-daemon parse

Y nos saldrá algo así

Profile-sync-daemon v5.73 on Arch Linux

Systemd service is currently active.
Systemd resync service is currently active.
Overlayfs v23 is currently active.

Psd will manage the following per /run/psd.conf settings:

browser/psname:  firefox/firefox
owner/group id:  juanpe/100
sync target:     /home/juanpe/.mozilla/firefox/jpg5q0bb.default
tmpfs dir:       /tmp/juanpe-firefox-jpg5q0bb.default
profile size:    63M
overlayfs size:  33M
recovery dirs:   none

browser/psname:  google-chrome-beta/chrome
owner/group id:  juanpe/100
sync target:     /home/juanpe/.config/google-chrome-beta
tmpfs dir:       /tmp/juanpe-google-chrome-beta
profile size:    98M
overlayfs size:  0
recovery dirs:   none


Activamos los servicios.

Edito: en Archlinux han cambiado el metodo y se ejecuta sin privilegios sudo

systemctl --user enable psd.service
systemctl --user start psd.service


sudo systemctl enable psd.service
sudo systemctl start psd.service

sudo systemctl enable psd-resync.service
sudo systemctl start psd-resync.service

Para comprobar que todo funciona con normalidad podemos usar de nuevo la opción

psd p

Y veremos algo así.

Systemd service is currently active.
Systemd resync service is currently active.
Overlayfs v23 is currently active.


Podemos ver los archivos de systemd activados con:

systemctl list-unit-files|grep ^psd

psd-resync.service                          enabled
psd.service                                 enabled
psd-resync.timer                            static


Ahora montaremos el caché de navegadores (y cualquier otro directorio) en RAM

Como ya hemos visto, con profile-sync-daemon podemos montar los perfiles de nuestros navegadores en RAM. Pero, a pesar de ello, algunos navegadores mantienen su caché fuera del perfil. Es el caso, por ejemplo, de Firefox, Chromium, Chrome y Midori. Estos suelen guardar sus cachés en algún directorio dentro de /home/usuario/.cache/navegador/ (mozilla en el caso de firefox).

Hay varias alternativas para asegurarnos su carga en RAM. Yo recurro a anything-sync-daemon, porque no requiere mantener una configuración específica por usuario, y conserva el contenido de la caché cuando el navegador sufre un cierre inesperado o se reinicia.

Básicamente, asd es un psd de propósito general: permite cargar cualquier directorio en RAM, vía tmpfs, sincronizándolo de forma periódica con una copia en el disco. Nosotros vamos a usarlo para la caché de los navegadores.

yaourt -S anything-sync-daemon

Lo configuramos en el directorio /etc/asd.conf

Dejándolo con la direcciones de los navegadores que usemos.

# Below is an example to whet your appetite.
#WHATTOSYNC=('/srv/http' '/var/lib/monitorix' '/foo/bar')
WHATTOSYNC=('/home/juanpe/.cache/mozilla' '/home/juanpe/.cache/google-chrome-beta')


Revisamos que todo este bien.

asd p

Y dará algo así.

Anything-sync-daemon v5.73 on Arch Linux

Systemd service is currently active.
Systemd resync service is currently active.
Overlayfs technology is currently inactive.

Asd will manage the following per /run/asd.conf settings:

owner/group id:     juanpe/100
target to manage:   /home/juanpe/.cache/mozilla
sync target:        /home/juanpe/.cache/.mozilla-backup_asd
tmpfs target:       /tmp/asd-juanpe/home/juanpe/.cache/mozilla
dir size:           21M
recovery dirs:      none

owner/group id:     juanpe/100
target to manage:   /home/juanpe/.cache/google-chrome-beta
sync target:        /home/juanpe/.cache/.google-chrome-beta-backup_asd
tmpfs target:       /tmp/asd-juanpe/home/juanpe/.cache/google-chrome-beta
dir size:           215M
recovery dirs:      none


Iniciamos los servicios.

sudo systemctl start asd.service
sudo systemctl enable asd.service

Ahora activamos la compilación en tmpfs.

Editamos como mucho ojo /etc/makepkg.conf

y lo dejamos así.

#-- Specify a directory for package building.
BUILDDIR=/tmp/makepkg
...



Y con esto ya esta todo para ahorranos escrituras y lecturas.
Gracias Brutico.

Yo hace tiempo que pienso en poner un tutorial para instalar Arch en UEFI con RAID+LUKS+LVM pero es que me da muchisima pereza.

Lo que yo hago para evitar escrituras innecesarias en el SSD es simplemente cambiar el swappines a 10 para que el sistema solo use la swap cuando se agote la RAM, pero tu sistema es mejor. Gracias, lo probare.

Un Saludo.
Se agradece el trabajo, para algunos puede ser util, pero realmente con la durabilidad de los SSD actuales, gran parte de este tutorial lo veo innecesario. Ojo, sin acritud.
yo en 3 años llevo sobre 8 Teras escritos, pero lo mio era un no parar en instalar distribuciones.
Pues imaginate, el que tengo ahora mismo tiene garantizados 150 TB escritos... cuantos años tengo que vivir para verlo morir? XD
Por eso digo, eso hace unos años vale, pero ahora mismo, la durabilidad es por lo menos igual que los HDD, de hecho, lo vas a cambiar antes de que muera seguro.
Gracias, lo tendré en cuenta para cuando haga actualización de esta parte esencial del sistema.
Buenas, he estado leyendo la guía, muy útil, ya que algunas cosas no las sabía.

Y tenía una duda, la partición /home la soléis meter en el SSD?

A veces es interesante, si instalas algún juego en esa partición, pues que vaya con el ssd que es más rápido, y no sé si es interesante poner toda la partición o es muy perjudicial, ya que se le hacían también bastantes escrituras.

Saludos
Voy a pensarme el usar fstrim.timer en vez de la opción discard en fstab [sonrisa]

Eso junto con lo de cambiar el planificador E/S y lo de la tmp en RAM me parece mas que suficiente.

@eric_14

Yo tengo la home en el SDD sin problemas. Lo que si que hago es dejar mis documentos, videos, fotos, etc en el HDD, creando solo un enlace simbólico en la home de mi usuario (SDD) hacía donde estan mis documentos (HDD). Pero lo que son archivos de configuración de programas, caches de navegadores, etc, yo los dejo en el SDD.

No entiendo cual es la gracia de usar un SDD y dejar TODO fuera del SDD.
Lo del planificador de la IO se nota?
Perfecto, pues pasaré la partición al ssd. Supongo que habrá que ir con ojo con las cache, de pacman y cosas así, pero bueno es ir mirando y si hay problema se hace enlace simbólico y ya.

Gracias
Yo, lo tengo en tres particiones. Sda es el SSD y el SDB es el mecánico:

sda      8:0    0 111.8G  0 disk
└─sda1   8:1    0 111.8G  0 part /
sdb      8:16   0   1.8T  0 disk
├─sdb1   8:17   0  18.6G  0 part /tmp
└─sdb2   8:18   0   1.8T  0 part /home


Es lo lógico creo yo, los programas al SSD y los datos (home y tmp) al HDD. Los juegos de Steam se instalan en home, asi que tampoco tengo problemas de espacio.
Así es como lo tengo ahora, pero si instalas juegos y quieres que carguen rápido tienes que meterlo en el SSD. Ahora supongo que da un poco igual, porque no hay juegos muy exigentes y cargan bien, pero si sacan alguno potente interesa que vaya al SSD. Y ficheros de configuración... supongo que prácticamente da igual, no habrá diferencia en rendimiento, pero si no se hacen muchas escrituras tampoco pasará nada si está en el SSD.

A mi me interesa hacerlo para que el HDD se pare, porque tengo un portátil y si rueda el HDD se calienta la zona donde pongo la mano, si el home está en el SSD no rodará y no se calentará. Es un poco raro poner el /home en el SSD para esto, pero me molesta un poco que se caliente jajaja

Saludos
Yo le meto un trim semanal y tira millas...
He seguido el manual y por ahora todo va bien, aunque solo tengo 6 GB de RAM por ahora. Muchas gracias por el curro!
el_Salmon escribió:He seguido el manual y por ahora todo va bien, aunque solo tengo 6 GB de RAM por ahora. Muchas gracias por el curro!

No pasa nada con seis vas bien. [oki]
Yo tengo 8gb y no llego al 50% casi nunca :cool:
Yo con 8GB solo me tira un poco al usar Virtualbox.

Respecto al SSD, soy el único que a instalado Arch sobre el sistema de archivos f2fs?
buena guia.

aunque yo volveria a gentoo [jaja]
think escribió:buena guia.

aunque yo volveria a gentoo [jaja]

En Eentoo llevo varios meses. XD
Brutico escribió:
think escribió:buena guia.

aunque yo volveria a gentoo [jaja]

En Eentoo llevo varios meses. XD


Hace un par de días instale Arch por que no me iba systemd bien en Gentoo

[jaja] [jaja]
Ha cambiado un poco el funcionamiento del profile-sync-daemon, pero vaya nada que no se busque en la Wiki y explique como activarlo con los nuevos cambios.

Me ha servido la guía, gracias.
Gracias...

Bueno he hecho unos cambias en el hilo a petición de un usuario y también he añadido los cambios que han hecho en la wiki de archlinux.
Que lo disfruteis :-)
Ojo con poner el planificador NOOP. Yo he experimentado bloqueos en algunos juegos, recomiendo deadline mejor.
$ sudo nano /etc/udev/rules.d/60-schedulers.rules
-------------------------------------------------
# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",
ATTR{queue/scheduler}="noop"


debe ser

$ sudo nano /etc/udev/rules.d/60-schedulers.rules
-------------------------------------------------
# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",ATTR{queue/scheduler}="noop"


por esto era por lo que te mande el mp para que editaras los quotes/codes
@sL1pKn07 Ahora lo edito. Gracias por el aviso.
Gracias.

Algunas otras opciones para mejorar el rendimiento y al mismo tiempo maximizar la vida util de los disco ssd??
El proximo mes, me llega una unidad NVMe, es por eso que estoy buscando lo mejor de lo mejor para estar preparado.

Ahora mismo, estas son las opciones que tengo activadas.

fstab
Imagen

montado
Imagen
27 respuestas