Améliorer la réactivité de Gnu/Linux sur son ordinateur portable

J'utilise aujourd'hui uniquement des ordinateurs portables chez moi, c'est un choix personnel. Parmi les quelques inconvénients de ces machines, il y a la lenteur des disques dur qui affecte la réactivité générale du système. Je présente ici les quelques optimisations que j'ai trouvé sur Internet et appliqué avec succès. Ces optimisations sont appliquées sur un ordinateur portable "standard" : Intel Core2 duo, 3Go de mémoire vive, un DD de 280 Go, carte graphique avec mémoire dédiée.

Choix du système de fichier et partitionnement du disque

Mon disque est partitioné comme suit :

• swap 4 Go
• /boot ext3 300 Mo
• / ext4 10 Go
• /home ext4 le reste du disque

J'ai une partition séparée pour /boot car lorsque ext4 fut proposé officiellement par les distributions majeures, grub ne le supporté pas encore, il fallait donc que la partition contenant le noyau soit en ext3 par exemple. J'ai toujours une partition de swap, bien que le système ne s'en serve presque pas. Enfin, j'ai une partition pour les données utilisateur séparée du reste du système. L'utilité d'une telle séparation est de pouvoir changer de distribution sans avoir à déplacer les données utilisateurs sur un autres disque. Nous verrons par la suite, que cela a un autre intérêt.
Le système de fichier utilisé est ext4 car il est a priori plus performant que ext3 et ext2. Je n'ai jamais utilisé JFS ou XFS bien qu'ils soient aussi très intéressants.

Tmpfs

La mémoire vive est plus rapide que mon disque dur ! Seulement, le système et les programmes ont besoin d'enregistrer des données temporaires sur le disque pour leur fonctionnement. Ces données sont écrites en plusieurs endroits en fonction de leur nature :

• /tmp pour des données temporaire supprimées à chaque redémarrage
• /var/tmp pour des données temporaires pouvant être réutilisées
• /var/run pour les données du programme en cours d'exécution
• /var/lock pour permettre à certains programmes de positionner des verrous

Grâce à tmpfs, nous pouvons monter ces répertoires en mémoire vive. Le gros point fort de tmpfs est d'allouer dynamiquement la mémoire vive, les répertoires montés de la sorte n'occupent que l'espace pris par les fichiers. Si nous regardons la taille du répertoire avec un gestionnaire fichier (ou bien df à la console), nous obtenons la taille maximale que peut avoir ce répertoire en mémoire vive. Par défaut, tmpfs défini cette taille maximale à la moitié de la mémoire vive disponible.
Pour utiliser tmpfs sur les répertoires sus-cités, il suffit d'ajouter les lignes suivantes au fichier /etc/fstab et de redémarrer son système :

tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/run tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0

Avec ces quelques lignes, je constate que mon système est plus réactif. C'est difficile à quantifier, je n'ai pas de mesures objectives à fournir. Cependant, les menus de XFCE et leur icônes s'affichent plus rapidement qu'avant, le gestionnaire de fichier Thunar affiche plus rapidement le contenu des dossiers, ... bref c'est plus fluide.
Attention, tout ne peut pas être mis en mémoire vive car les données qui y sont placées sont perdues avec l'extinction de l'ordinateur. Il existe bien sûr possible de créer des scripts pour sauvegarder dans une archive les données au moment de l'arrêt. D'autres scripts rechargent ensuite ces données dans la phase de démarrage du système. Je n'ai pas mis en œuvre cette possibilité.

Le cas Firefox

Firefox gère un cache sur le disque dur dans le répertoire de l'utilisateur. Il est possible de paramétrer la localisation de ce cache et le placer dans le répertoire /tmp. Pour cela, dans la barre d'adresse de Firefox, il suffit de taper about:config, valider l'avertissement puis ajouter la clé browser.cache.disk.parent_directory et lui donner comme valeur /tmp. Une fois cette modification faite, si nous relançons Firefox, nous constatons que la navigation est un peu plus fluide qu'auparavant.

Le tuning ext4

Il est possible de gagner encore en performance en jouant sur certains paramètres de montage des partition dans /etc/fstab. Voici un exemple de ligne je vais détailler :

/dev/sda2 / ext4 noatime,data=writeback,barrier=0,nobh,commit=100,nouser_xattr 0 1

• L'option noatime désactive l'acces time. Par défaut, à chaque fois, que nous accédons à un fichier, ext4 écrit la date d'accès à ce fichier sur le disque! Dans le cadre d'un usage personnel, cette opération couteuse en temps peut être désactivée sans que cela affecte le fonctionnement du système.
• L'option data=writeback change le mode de journalisation du système de fichier. Dans ce mode les données peuvent être écrites sur le disque après que leur méta-données soient enregistrées. Cela signifie qu'en cas de plantage, si une opération d'écriture était en cours certaines données ne seront pas retrouvées. Dans mon cas (partition racine), sauf en cas d'installation d'un nouveau programme ou de mise à jour du système, je ne risque pas grand chose. Attention, lorsque cette option est activée sur la partition racine, celle-ci doit être d'abord montée en lecture seule pour que la commande suivante lui soit appliquée : tune2fs -o journal_data_writeback /dev/sdXX où XX est la partition modifiée, sda2 dans notre exemple. Dans le cas contraire, certains programmes comme le serveur X refusent de démarrer. Un fois cette opération faite, on peut redémarrer normalement son ordinateur.
• L'option commit=100, modifie l'intervalle de mise à jour du journal en seconde. Il s'agit d'une opération de synchronisation entre les données et les méta-données. Par défaut, elle est positionnée à 5 secondes. En la mettant à 100, cela signifie qu'en cas de plantage, je peux perdre jusqu'à 100 secondes d'historique.
• L'option nouser_xattr désactive les attributs étendus des utilisateurs. Pour un usage personnel, cette fonctionnalité n'est pas très importante.
• L'option nobh nécessite que la première option data=writeback soit utilisée.
• L'option barrier=0 ne doit être activée que lorsqu'on a une alimentation de secours ... ce qui est le cas sur un portable :-). Concrètement, cette option renforce l'ordre des commits dans le journal. Encore une fois, sur la partition racine, je ne risque pas grand chose.

Les options les plus significatives sur la réactivité du système sont noatime et data=writeback.

Et les logs ?

Il est aussi possible de mettre le répertoire /var/log en mémoire vive. Cela signifie juste que je perd l'historique des actions sur mon ordinateur. Dans le cadre d'un usage domestique, cela pas pas beaucoup d'importances. Par contre, il faut penser à désactiver le service de log du noyau.

Encore plus de réactivité ?

Pour les plus fortunés, il est possible d'acheter un ordinateur portable avec 2 emplacements pour disque dur et de les configurer en raid 0. Il est aussi possible de remplacer l'unique disque dur du portable par un disque SSD ... très cher.
Une autre solution moins onéreuse peut être d'acheter une Express card SSD, on en trouve de quelques Go pour une cinquantaine d'euros. L'idée est de mettre la partition racine sur ce disque et le reste sur le disque dur.