Que vous ayez un SSD ou non, je pense que ce qui va suivre va vous intéresser. Ceux qui ont un SSD vont apprécier le fait de ne pas écrire constamment sur le disque et de tuer son espérance de vie. Et les autres vont aimer le fait d’accélerer l’utilisation de caches. Rien de révolutionnaire ici, nous allons utiliser des RAMDisks et soulager, si vous en avez, nos SSD. Je vous précise que vous n’aurez aucune surprise ici, je vais parler de méthodes vieilles de plusieurs siècles (ok… de plusieurs années) et qui ne sont absolument pas des hacks ou des nouveautés. Rien que du bon sens !

TL;DR

[EDIT] 03/11/2015 - Une modification importante a été ajoutée suite à différents commentaires sur Google+. Ainsi, je vous propose une partie supplémentaire de “sauvegarde de cache”

[EDIT] 03/11/2015 - Bonne remarque dans les commentaires à propos de l’utilisation de “rsync” dans le cas où vous souhaitez sauvegarder vos caches. L’idée est de ne plus supprimer la sauvegarde de cache et de la synchroniser lors de l’extinction/démarrage avec le cache. Voir le point 5 et les explication à propos des caches utilisateurs dans l’article. Merci à Frédéric Thouin auteur de la distribution Viperr.

Je vous demande de prendre tout ce qui suit, y compris les explications, avec des pincettes ! Lisez et comprennez avant de lancer les commandes. Si vous vous loupez, vous pouvez faire planter le redémarrage. Rien n’est irreversible, vous pouvez réparer sans souci mais évitez-vous une crise d’arrachage de cheveux et ne faites rien sans comprendre les commandes et éditions de fichiers qui suivent.

Pour résumer:

• utilisez des RAMDisk pour vos caches (cache utilisateur, cache dnf, cache packagekit…) et adaptez la taille max selon votre RAM
• utilisez des services pour mettre en place les caches
• faites un TRIM régulier sur les disques SSD (si vous en avez un)

Donc rien de spécialement “génial” mais un minimum qui va soulager votre SSD et utiliser votre RAM pour le cache.

1. Utiliser un RAMDisk pour /tmp même si les gens de chez Debian sont pas d’accord. C’est déjà le cas sur Fedora, sinon:

   Vérifiez que tmp n’est pas déjà monté en ramdisk:

   $ mount | grep /tmp
   tmpfs on /tmp type tmpfs (rw,seclabel)
   

   Notez bien que “seclabel” est ajouté par SELinux, ne le mettez pas vous-même. Il sera ajouté par SELinux.

   Si le répertoire “/tmp” nest pas monté, éditez /etc/fstab et ajoutez la ligne:

   tmpfs       /tmp    tmpfs   rw     0   0
   

   Pensez à supprimer le contenu de /tmp AVANT de monter /tmp,

2. Montez les caches utilisateurs dans un ramdisk

   Fermez toutes les sessions, allez ensuite dans un tty (CTRL+ALT+F1) et connectez-vous en root:

   for c in /home/*; do
       mv $c/.cache $c/oldcache
       echo -e "tmpfs\t$c/.cache\ttmpfs\tnoatime,nodev,nosuid,size=500M\t0\t0" >> /etc/fstab
       mount $c/.cache
       mv $c/oldcache/* $c/.cache
       rm -rf $c/oldcache
   done
   

3. Placez les caches dnf et PackageKit dans un ramdisk

   systemctl stop PackageKit
   rm -rf /var/cache/PackageKit/*
   rm -rf /var/cache/dnf/*
   echo -e "tmpfs\t/var/cache/PackageKit\ttmpfs\tdefaults,noatime\t0\t0" >> /etc/fstab
   echo -e "tmpfs\t/var/cache/dnf\ttmpfs\tdefaults,noatime\t0\t0" >> /etc/fstab
   mount /var/cache/PackageKit
   mount /var/cache/dnf
   systemctl start PackageKit
   

4. Créez un service pour charger le cache dnf quand le réseau est prêt

   Créez le fichier /etc/systemd/system/mydnfcache.service:

   [Unit]
   Description=DNF cache creation 
   After=network-online.target
   Wants=network-online.target
   
   [Service]
   ExecStart=/usr/bin/dnf makecache
   
   [Install]
   WantedBy=multi-user.target
   

   Activez le service pour qu’il démarre au prochain redémarrage, et lancez le service:

   systemctl enable mydnfcache
   systemctl start mydnfcache
   

5. Si vous souhaitez sauver vos caches, par exemple pour PackageKit qui, lors d’une mise à jour, va redémarrer et en plus retrouver le cache, vous pouvez faire ceci:

   Créez un script de sauvegarde de cache /usr/local/bin/savecaches.sh:

   #!/bin/bash
   
   PKGKIT=/var/cache/PackageKit
   DNF=/var/cache/dnf
   
   # create backup for PackageKit and dnf
   [[ -d  ${PKGKIT}.bkp ]] || mkdir -p ${PKGKIT}.bkp
   [[ -d  ${DNF}.bkp ]]    || mkdir -p ${DNF}.bkp
   
   case $1 in
   
   	restore)
   		# move backup to real cache
   		for c in $PKGKIT $DNF; do 
   			rsync -ra --delete-after ${c}.bkp/ ${c}/
   		done
   		;;
   
   	save)
           # restore backup cache
           for c in $PKGKIT $DNF; do 
               rsync -ra --delete-after ${c}/ ${c}.bkp/
           done
           ;;
   
   esac
   

   Créez un “unit” systemd qui démarrera avant PackageKit, /etc/systemd/system/cachesave.service

   [Unit]
   Description= Save caches at shutdown - reset cache at startup
   Before=packagekit.service packagekit-offline-update.service
   
   [Service]
   Type=oneshot
   RemainAfterExit=yes
   ExecStop=/bin/bash /usr/local/bin/savecaches.sh save
   ExecStart=/bin/bash /usr/local/bin/savecaches.sh restore
   
   [Install]
   WantedBy=multi-user.target
   

   Puis activez le service

   sudo systemctl enable cachesave
   sudo systemctl start cachesave
   

   Vous pouvez aussi créer un “unit” pour vos caches utilisateurs en suivant le même modèle. Voir l’article…

6. Si vous avez un SSD, vérifiez qu’il accèpte la commande “TRIM” - si oui:

   systemctl start fstrim.timer
   systemctl enable fstrim.timer
   

Voilà, un conseil maintenant: redémarrez votre machine. Tout devrait bien se passer.

Ok, tu m’expliques ?

Le TL;DR est conséquent mais je pense que quelques explications peuvent vous aider à comprendre.

Le but de toutes ces opérations est simple: utiliser un peu plus la RAM que ce qui est prévu par défaut. En effet, Linux (du moins les distributions Linux) a l’intérêt de pouvoir tourner sur des petits systèmes avec très peu de RAM. Mais dans la plupart des cas, les postes utilisateurs sont plutôt caustauds.

J’entend par là que vous avez certainement pas mal de mémoire RAM (plus de 4Go, certains se balladent avec plus de 32Go de RAM…) et que celle-ci est finalement pas exploitée complètement. Or, la RAM est très rapide, bien plus que votre HDD traditionnel, et plus rapide que les SSD actuels.

Donc, si vous avez un poste assez récent, vous pouvez utiliser la RAM comme “disque dur temporaire”.

C’est justement ce que nous appelons un RAMDisk.

Mais utiliser un RAMDisk a une conséquence non négligeable… il se vide quand la machine est éteinte. Et par conséquent, il va falloir faire quelques réglages.

Ensuite, les gens ayant un SSD tremblent face à leur durée de vie dite “limitée”… utiliser quelques RAMDisk va calmer un peu vos frayeurs.

Les RAMDisk

Sous Windows, c’est pas drôle à faire. Enfin j’en sais rien mais de ce que j’en ai lu sur le net, il faut installer un logiciel, paramétrer des trucs à la souris… franchement j’ai remercié le ciel d’être sous un Unix Like (et pourtant je ne suis pas croyant)

Un RAMDisk n’est pas un disque dur à brancher sur votre système. C’est bêtement un disque temporaire accessible comme un répertoire (comme tout périphérique sous Linux) dont le contenu est écrit en RAM.

Il y a déjà pas mal de RAMDisk préconfigurés sur votre distribution. Depuis quelques années, le répertoire /dev/shm (shared memory - mémoire partagée) est justement un répertoire donc le contenu est en RAM. Certains programmes écrivent dedans pour partager des informations sans avoir à écrire sur le disque. C’est effectivement très simple d’écrire un fichier contenant des informations.

Le système de montage est “tmpfs” ou “ramfs”. La différence entre les deux est simple: si la RAM est saturée, un point de montage TMPFS va “swapper”, c’est-à-dire utiliser votre disque dur temporairement, le temps que de la place se libère. Alors que le RAMFS va misérablement bloquer. C’est débile ? non, c’est voulu ! RAMFS est surtout utilisé pour des programmes qui ne veulent surtout pas toucher au disque.

Pour nous, humbles utilisateurs, TMPFS est bien plus sécurisé.

Si vous voulez tester, créer un répertoire /mnt/testramdisk et montez un espace tmpfs dessus:

mkdir /mnt/testramdisk
mount -t tmpfs tmpfs /mnt/testramdisk

Voilà, si vous écrivez dans ce répertoire, et bien le fichier sera dans la RAM, et il ne sera pas écrit sur votre disque dur. Y accéder est très rapide ! Bien plus que depuis votre disque dur.

Alors attention, écrire un fichier de 4Go dans le répertoire, alors que vous avez 2Go de RAM va effectivement déborder ! C’est pourquoi on doit:

• limiter la taille du ramdisk
• éviter de les utiliser pour tout et n’importe quoi si on a peu de RAM

Une option intéressante au point de montage est justement “size”. Testons:

umount /mnt/testramdisk
mount -t tmpfs tmpfs /mnt/testramdisk -o defaults,size=1Mo

Le disque ne fait que 1Mo, essayez de déposer un fichier de plus de 1Mo et le message est sans appel “no space left on device”. C’est une sécurité nécessaire, croyez-moi.

Allez, on nettoie et on passe à la suite:

umount /mnt/testramdisk
rm -rf /mnt/testramdisk

Montage des caches

Il existe un paquet de “caches” sur votre installation.

• les répertoires utilisateurs “home” ont un répertoire “.cache” dans lequel écrivent Google Chrome, Firefox, Gnome, votre client mail…
• des répertoires systèmes pour dnf, packagekit, et j’en passe…

Un cache est un espace qui peut être effacé sans affecter vos données. J’insiste, si un programme plante quand le cache est vidé, alors ce programme est mal foutu. Personnellement je n’en connais pas… Soit dit en passant, il convient de ne pas vider le cache d’un programme qui est en train de l’utiliser. Non pas que ce soit grave, mais il sera peut-être nécessaire de le redémarrer pour qu’il réinitialise le cache.

Bref, on a de la RAM, on va faire en sorte que notre utilisateur arrête d’écrire sur le disque le cache. J’ai vérifié ce que mon utilisateur en cours utilise dans $HOME/.cache. Je ne dépasse pas les 200Mo par session. Je me prends un marge et j’estime que sur mes 8Go de RAM, je peux utiliser 500Mo pour mon utilisateur.

Donc, j’édite /etc/fstab et je mets:

tmpfs   /home/metal3d/.cache    tmpfs   noatime,nodev,nosuid,size=500M      0       0

Évidemment, vous remplacerez “metal3d” par votre nom d’utilisateur…

Les options que j’ai utilisé:

• noatime parce que je n’utilise pas de logiciel qui se basent sur la date d’accès au fichier
• nodev hors de question de mettre des périphériques dans le cache
• nosuid pour ne pas les bits suid - inutile dans le cache
• size=500Mo pour autoriser 500Mo maximum dans le cache

Ne montez pas le disque de suite, il faut vider le répertoire avant de le monter. Car si vous montez le disque de suite, le contenu sera toujours présent sur le disque mais inaccessible - à moins de démonter le cache. Donc au lieu de perdre bêtement cet espace, on va couper la session Gnome (ou KDE, ou XFCE…) et allez dans un TTY (CTRL+ALT+F1) pour s’y connecter en “root”. Puis on supprime ce cache, et on le monte:

rm -rf /home/metal3d/.cache/*
mount /home/metal3d/.cache

Évidemment, vous remplacerez “metal3d” par votre nom d’utilisateur…

Voilà, vous pouvez vous reloguer sur Gnome…

On va en faire autant pour les cache dnf et PackageKit

Dans /etc/fstab:

tmpfs   /var/cache/dnf              tmpfs   defaults,noatime        0   0
tmpfs   /var/cache/PackageKit       tmpfs   defaults,noatime        0   0

On fait pareil que pour les users, on vide le répertoire et on le monte. Par contre, on coupe le service PackageKit avant, histoire de ne pas lui couper la chique en plein milieu d’une opération.

systemctl stop PackageKit
rm -rf /var/cache/PackageKit/*
rm -rf /var/cache/dnf/*
mount /var/cache/dnf
mount /var/cache/PackageKit
systemctl start PackageKit

Voilà qui est fait !

Réparer PackageKit

[EDIT] partie ajoutée le 03/11/2015

Un souci va apparaitre, si vous décidez d’utiliser PackageKit pour vos mises à jour, il va y avoir un effet de bord très important: ça ne marchera plus.

La raison est la suivante: l’interface vous propose de redémarrer. Or, en redémarrant, le RAMDisk est supprimé et les RPMs qui ont été téléchargés sont perdus. Vous avez alors trois possibilités:

• vous ne mettez pas /var/cache/PackageKit en RAMDisk
• vous utilisez “dnf update” au lieu de rebooter
• vous sauvegardez le cache lors de la fermeture, et vous le récupérer en RAMDisk au démarrage

Pour le troisième point, il suffit de faire un script et un fichier “unit”. Le script est simple et à placer, par exemple dans “/usr/local/bin/savecaches.sh”:

[EDIT] Utilisation de rsync - plus de suppression du backup en dur. La synchro est plus rapide et limite l’accès disque (ainsi que les écritures).

#!/bin/bash

PKGKIT=/var/cache/PackageKit
DNF=/var/cache/dnf

# create backup for PackageKit and dnf
[[ -d  ${PKGKIT}.bkp ]] || mkdir -p ${PKGKIT}.bkp
[[ -d  ${DNF}.bkp ]]    || mkdir -p ${DNF}.bkp

case $1 in

	restore)
		# move backup to real cache
		for c in $PKGKIT $DNF; do 
			rsync -ra --delete-after ${c}.bkp/ ${c}/
		done
		;;

	save)
        # restore backup cache
        for c in $PKGKIT $DNF; do 
            rsync -ra --delete-after ${c}/ ${c}.bkp/
        done
        ;;

esac

Basiquement, appeler ce script avec un argument “save” va sauver le cache sur le disque dur, et l’argument “restore” va simplement le remettre en RAM (et supprimer le répertoire du disque dur).

Maintenant, on va créer un fichier “unit”, je vais expliquer après à quoi servent les directives intéressantes. Le fichier à créer est “/etc/systemd/system/cachesave.unit”:

[Unit]
Description= Save caches at shutdown - reset cache at startup
Before=packagekit.service packagekit-offline-update.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/bin/bash /usr/local/bin/savecaches.sh save
ExecStart=/bin/bash /usr/local/bin/savecaches.sh restore

[Install]
WantedBy=multi-user.target

C’est assez simple:

• RemainAfterExit=yes signifie que quand la commande ExecStart a fonctionné, on garde l’état “actif” afin de ne pas le redémarrer en cas de dépendance.
• ExecStart=… lance la commande au démarrage du service, donc dans notre cas ce sera quand packagekit ou packagekit-offline-updown aura démarré (et pas avant)
• ExecStop=… lance cette commande quand le service est éteint, donc quand la machine redémarre ou s’éteind

On perd un peu de l’optimisation d’écriture pour les SSD, car pour le coup nous allons écrire réellement des fichiers sur le disque. Mais en l’occurrence, vous aurez quand même une belle optimisation de lecture des paquets lors du dépaquetage à la mise à jour.

Si en plus, comme moi, vous éteignez rarement votre PC, la sauvegarde du cache sera rare.

Et pour mes caches utilisateurs ?

[EDIT] partie ajoutée le 03/11/2015

[EDIT] utilisation de rsync pour limiter les écritures/accès disque et optimiser la vitesse de synchro - plus de suppression de backup en dur.

Effectivement vous pouvez avoir envie de faire pareil pour vos caches utilisateurs. Le principe reste le même: vous créer un script qui sauve tous les répertoires “/home/*/.cache” dans “/home/*/.cache.bkp” et inversement. Par exemple dans “/usr/local/bin/savehomecaches.sh”:

CACHE=.cache
BACKUP=.cache.bkp

# commands
case $1 in
    save)
        for c in /home/*; do
            # create backup cache directory if not exists an
            # ensure that owner is correct
            if [[ ! -d ${c}/${BACKUP} ]]; then
                mkdir -p ${c}/${BACKUP} 
                chown -R $(stat -c "%U:%G" $c) ${c}/${BACKUP}
            fi

            # synchronize cache to backup
            rsync -ra --delete-after ${c}/${CACHE}/ ${c}/${BACKUP}/
        done
        ;;

    restore)
        for c in /home/*; do
            # synchronize backup to cache
            rsync -ra --delete-after ${c}/${BACKUP}/ ${c}/${CACHE}/
        done
        ;;
esac

Et pour l’unit:

[Unit]
Description=Home cache backup/restore

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/bin/bash /usr/local/bin/savehomecaches.sh save
ExecStart=/bin/bash /usr/local/bin/savehomecaches.sh restore

[Install]
WantedBy=multi-user.target

Ici, plus besoin d’attendre les services PackageKit. Donc on ne met pas de “Before” dans l’unit. La synchronisation va se faire, bha, quand ça peut se faire… Mais rapidement, bien avant que vous ne vous loguiez à Gnome.

Bref, encore une fois, vous allez écrire sur votre SSD, ce qui induit une usure (voir la suite de l’article). C’est donc une opération propre à de l’optimisation lors de l’utilisation de votre machine, mais pas pour la réduction d’usure du SSD. Dans le même temps, il est clair que cette opération de sauvegarde de cache sur le SSD n’est pas pire que si vous ne mettiez pas de RAMDisk.

Donc, pas de panique.

Et puisque j’ai modifié l’article en fonction des commentaires, et que j’utilise rsync, et bien le ressenti sur le disque est encore adouci. Une nouvelle fois, merci à Frédéric Thouin pour cette idée !

Recharger le cache au démarrage pour DNF

La commande “dnf” se met à jour si le cache est vide ou s’il est trop vieux. Le souci c’est que nous le vidons à chaque redémarrage, donc la prochaine fois que vous allez demander une mise à jour ou une installation, et bien “dnf” va télécharger les informations de dépôts.

PackageKit le fait avec un service… on va en faire autant.

À tous ceux qui ont bavé sur systemd, je vous mets au défi de faire ce que je vais faire en si peu de caractères. C’est-à-dire de faire en sorte que le cache se charge quand on a accès au net, au démarrage du système.

Créez un fichier /etc/systemd/system/mydnfcache.service:

[Unit] 
Description=DNF cache creation 
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/dnf makecache

[Install]
WantedBy=multi-user.target

Et activez-le pour le démarrage:

systemctl enable mydnfcache

Pour le lancer de suite:

systemctl start mydnfcache

Voilà… c’est fini.

Tu chipotes pas un peu ?

Certains me disent à propos de mes montages en RAMDisk:

À comparer du nombre de trucs écrits par ton OS par rapport à tes écritures, tu te fais suer pour rien.

Ma réponse est la suivante:

Non, je ne chipote pas. D’une part monter des RAMDisk est super simple et mon paramétrage ne bouge pas. J’ai passé 5 minutes à toucher mon fstab, ça vaut le coup.

D’autre part, le nombre de fichiers que j’écris, même involontairement, est très conséquent. On parle de plusieurs gigaoctets par jour. Entre le cache navigateur, le cache de mails, les pages web et mes développements, l’intérêt des caches montés dans un tmpfs (ramdisk) est franchement loin d’être insignifiant.

À vous de voir… Si vous pensez que j’ai tort, ne faites rien de ce que je dis, après tout ce n’est que mon avis.

Et au fait, mon SSD ?

Un SSD ça fait peur quand on l’achète. Oui c’est super rapide, ça soulage vraiment, et le confort de travail est réellement augmenté. Honnêtement, démarrer un PC en moins de 3 secondes, charger des programmes conséquents en un instant et voir enfin son CPU ne plus être bridé par les lectures disque, ça change la vie. Et je pèse mes mots.

Mais tous les articles du net que j’ai lu me sortaient que

• la durée de vie allait décroitre à mesure que j’allais écrire sur mon disque
• ça allait être de plus en plus lent
• j’allais devenir stérile
• mes ongles allaient prendre feu
• je serai voué à écouter du Céline Dion jusqu’à la fin des temps…

Et vraiment, Céline Dion, je peux pas…

Un SSD n’a pas de mécanique comme sur les HDD traditionnel (on dit “mécanique”). Un HDD a une série de disque magnétiques en rotation. La tête de lecture lit les “blocs” quand ils passent au dessous. Donc il faut un temps pour que le disque se trouve sous la tête afin qu’un bloc soit lut. Et pour reconstituer un fichier, il faut lire plusieurs centaines, voir plusieurs miliers de blocs. C’est lent…

Un SSD par contre n’a pas ces soucis. Il ne contient que de l’électronique. C’est comme si vous aviez un bloc de RAM dont la mémoire ne s’efface pas quand on coupe le courant. Sans la mécanique, les temps de lecture/écriture sont très rapide. On parle de plusieurs centaines de fois plus rapide ! Vous imaginez bien (si vous n’avez pas de SSD) le gain de performance, les temps de démarrages ou encore le gain significatif de batterie pour les portables puisque nous n’avons pas de moteur à faire tourner.

Pourquoi cette frayeur répandue sur ces articles ? Aurai-je eu tort d’acheter mon SSD ? Je vous le dis de suite, faut arrêter d’avoir peur. D’une part parce que votre SSD va tenir bon pendant quelques années, et surtout parce qu’on peut réduire les risques. D’abord avec les RAMDisk (puisqu’on ne va pas écrire sur le SSD) et ensuite en suivant quelques réglages que je vais vous donner. Bon ça sera pas le sauvetage du siècle, mais ça peut franchement augmenter la durée de vie selon votre utilisation. Mais d’abord, un peu de théorie.

1 ko à pied, ça use, ça use…

En gros, le souci du SSD, c’est que quand vous écrivez sur un block, ce dernier s’abîme… et après 100.000 écritures environ, ce block de 4ko sera inutilisable.

Vous pouvez d’ailleurs connaitre l’état d’usure (wearout) de votre disque, simplement avec la commande “smartctl” fourni dans le paquet “smartmontools”:

sudo smartctl -a /dev/sda

Cherchez la ligne “Wear_Leveling_Count” ou contenant “Wear” (parfois ça change d’une verison à l’autre de smartctl). Vous verrez alors plusieurs colones. La colonne “VALUE” indique son état de vie. Donc une valeur de “100” indique que vous avez “100%” de la capacité de vie.

À partir de 20%… je vous conseille fortement de sauvegarder vos données et de rapidment aller acheter un autre disque dur.

Continuons…

Pour éviter d’abïmer rapidement les blocks en effacant les valeurs qui s’y trouvent, les constructeurs ont eut une idée fabuleuse: ne pas écrire dedans quans on a des blocs propre plus loin. Par con hein…

Attention je vulgarise (et ça va rester un peu confus pourtant):

Quand on efface un fichier, on indique simplement que, sur le disque, les blocs utilisés pour ce fichier sont “libres”. On efface pas vraiment le contenu, c’est la table des matières qui n’a plus l’index pour ce contenu.

Si vous voulez maintenant écrire un nouveau fichier, on va aller sur le bloc libre et écrire une donnée. Or, à force de faire cela, on va user les premiers blocs plus vite que les derniers. Donc pour éviter cette usure, le contrôleur de disque va chercher des blocs qui ne contiennent pas de valeur (des blocs avec aucune charge). Et pour ce faire, il va tester les blocs qu’il trouve en chemin. Si le bloc n’est pas utilisé par une resource et qu’il a une valeur nulle, alors il peut l’utiliser. Sinon, il en cherche un autre, et un autre, etc… car il ne veut pas abîmer les blocs en écrivant “null” (vidage de charge) et en chargeant le bloc ensuite. C’est pas idiot, croyez moi, c’est même très intelligent.

Mais cela induit un effet de bord: le contrôleur va devoir tester chaque bloc pour vérifier s’il est vide dans les zones où la donnée est considéré comme “effacée”. Et ça, ça ralenti le système. Plus vous créez et supprimez des fichiers, plus ça ralenti les process. Donc, il faut de temps en temps faire en sorte que le contrôleur ne se prennent pas la tête à vérifier tous les blocs.

Fin de la théorie, on passe à l’action.

TRIM

L’idée est donc de soulager ces tests de temps en temps en mettant vraiment un zéro (en vidant la charge) sur les blocs qui ont reçu un jour une donnée et dont on a supprimé le contenu. C’est ce que nous appelons un “TRIM”. Pour simplifier, on va chercher tous les blocs du disque, vérifier s’ils sont utilisés par une ressource (fichier) et mettre “null” dedans (vider la charge) si ce n’est pas le cas. Par conséquent, le contrôleur va pouvoir écrire dedans sans avoir à l’éffacer, et il ne va pas chercher d’autres blocs libres.

Pour vérifier si vous pouver “trimer” votre disque:

$ sudo hdparm -I /dev/sda | grep -i trim 
 *  Data Set Management TRIM supported (limit 8 blocks)

Si vous n’avez pas de ligne qui apparait… bha désolé pour vous.

Sur Fedora, et certainement d’autres distributions, il existe un service systemd qui va le faire pour vous:

systemctl enable fstrim.timer
systemctl start fstrim.timer

Sinon, si vous n’avez pas ce service, vous pouvez le faire vous-même.

Sous linux, la commande “fstrim” va donc faire le “TRIM”. D’ailleurs le service systemd “fstrim” ne fait ni plus ni moins qu’un “fstrim -a” toutes les semaines.

Donc, si vous n’avez pas ce service sur votre système, vous pouvez créer une tâche “cron” qui s’en occupera.

Selon le nombre d’écritures sur le disque, vous pouvez placer le script suivant dans /etc/cron.weekly ou /etc/cron.daily. La recommandation est “weekly” à moins que vous ayez vraiment un nombre très conséquent d’écritures disques

Le script /etc/cron.weekly/fstrim:

#!/bin/sh
LOG=/var/log/fstrim.log
echo "===" $(date -R) "===" >> $LOG
fstrim -a 2>&1 >> $LOG

Rendez-le exécutable:

chmod +x /etc/cron.weekly/fstrim

Tous les dimanches à minuit, ou au prochain démarrage si cette date est passée et que la machine n’était pas active, un “TRIM” est fait sur le disque.

Quelques autres idées

Les RAMDisk sont faciles à créer. Personnellement quand je bosse sur un développement qui génère des fichiers temporaires, je me débrouille pour écire dans “/tmp” ou mon “.cache” personnel. Mais parfois ce n’est pas facile de changer le comportement de l’outil de génération.

Si, et seulement si les fichiers générés sont jetables, vous pouvez repérer simplement le répertoire de sortie de ces fichiers et monter un ramdisk.

Je prends un exemple… on bosse avec gulp qui génère des fichiers temporaires dans un répertoire “.tmp”, lui-même contenu dans le répertoire du projet. Comme on est 5 à bosser dessus, et qu’on est pas tous sur le même OS, on impose pas l’écriture dans “/tmp”. Du coup, je monte un disque:

rm .tmp/*
sudo mount -t tmpfs tmpfs $(pwd)/.tmp 
gulp serve

Le résultat est que je n’écris pas ce cache sur le disque. Je n’impacte pas mon SSD et en plus l’accès est bien plus rapide.

Idem avec les “builds”, les fichiers n’ont pas vocation de rester sur mon disque dur. Je prend l’exemple de mon blog (développé en Go). J’ai un paquet de css à minifier dans un fichier. Et bien je monter un disque tmpfs dans un coin et j’écris dedans. Quand je teste mon application, l’accès à ce fichier est rapide et je n’impacte pas mon SSD…

Bilan

Personnellement j’ai ressentis les effets des caches utilisateurs avec l’utilisation d’un HDD traditionnel, moins avec un SSD. Quand je dis “moins”, je ne veux pas dire “pas du tout”. Simplement qu’en toute logique, le ressenti est plus léger car les accès disques SSD sont très rapides.

Donc, pour commencer, que vous soyez avec un SSD ou non, de toutes manières je vous recommande de monter des RAMDisk pour les données temporaires - la vitesse de lecture en RAM va relativement soulager votre travail. Pensez à utiliser “/tmp” et (si vous avez suivi mon article) votre répertoire “~/.cache”. Montez à la volée des RAMDisks.

Niveau mémoire, l’ensemble de mes RAMDIsks prennent 1Go réel sur mes 8Go de RAM. Htop ne me montre pas de niveau alarmiste, bien au contraire - et j’en suis toujours étonné.

Le fait d’avoir mis un cache sur PackageKit et dnf a largement accéleré les grosses mises à jour, par contre il faut avouer que pendant la mise à jour l’utilisation de la RAM grimpe en flèche. Logique, l’ensemble des RPM se trouve dans le cache pendant l’installation, et par conséquent dans la RAM puisque le répertoire est un RAMDisk. Donc clairement, il vous faut de la RAM, un minimum de 4Go pour ne voir le pc ralentir pendant une mise à jour, et je pense que 8Go est le minimum recommandé pour ne pas avoir trop de ressenti. Au prix de la RAM, ne nous privons pas. Cela soulage le SSD, ça soulage les nerfs des propriétaires de HDD et c’est franchement facile de configurer des RAMDisk sous Linux du moment où on comprend comment les monter.

Personnellement, je réfléchis à mettre encore d’autres répertoires en RAM, et à me payer 16Go, voir 32Go de RAM…

Quant au TRIM, et bien je ne peux pas trop vous dire ce qu’il en est. J’ai suivi des recommandations, je n’ai pas de points de comparaisons sous la main. Si vous en avez, contactez moi, commentez l’article, bref, tenez-moi au courant.