Ubuntu sur un disque SSD

Récemment, j’ai constaté que le disque dur de mon PC montre des signes de faiblesse. Bon, après 5 ans de bons et loyaux services (15000 heures de fonctionnement), c’est acceptable.

J’ai donc décidé d’acheter un nouveau disque dur. Et, pour découvrir les joies des technologies récentes, j’ai choisi un disque SSD : plus performant, plus rapide, plus silencieux, plus économique… J’ai opté pour le seul disque à moins de 100 € vendu par l’une des seules boutiques d’informatique du coin, c’est-à-dire un Verbatim de 128 Go.

Je me suis documenté, afin d’installer ce disque au mieux…

Installation

Pour l’installation d’Ubuntu, je fais quelque chose de presque classique… D’abord, je démarre en mode « essayer Ubuntu avant de l’installer » : cela permettra de faire certaines manipulations ultérieurement, avant de redémarrer sur le système final (en choisissant « installer Ubuntu », on ne peut pas faire ces manipulations, tout ce qu’on peut faire à la fin de l’installation c’est redémarrer).

Pour le partitionnement, je fais quelque chose de plutôt classique :

  • 20480 Mo pour /, en ext4 (partition primaire)
  • le reste du disque pour /home, en ext4 (partition primaire)

Pas de swap ! Je me permets ça car j’ai 4 Go de mémoire vive, ce qui est suffisant pour une utilisation basique. On peut toutefois laisser de la swap, mais il faut savoir qu’à chaque utilisation de la swap, c’est des cycles d’écriture « dépensés » sur le SSD. Au moins là, il n’y a aucun risque.

À la fin de l’installation, je ne redémarre pas tout de suite. J’effectue quelques modifications afin d’améliorer encore ce système…

Partitions et points de montage

En l’occurrence, je fais trois choses :

  • ajout de l’option « noatime » pour les partitions disque : de cette manière, le système n’enregistre pas la dernière heure d’accès à chaque fichier : ça évite une écriture pour chaque lecture ;
  • ajout de l’option « discard » : ça permet d’optimiser le fonctionnement du SSD ; en gros, lors de l’effacement d’un fichier son contenu n’est pas réellement effacé, il est juste déréférencé, le disque dur écrase simplement le contenu lorsqu’il réutilise l’espace concerné ; par contre, un disque SSD est obligé de libérer l’espace avant d’écrire une nouvelle information, cette option permet de forcer cette libération d’espace dès l’effacement du fichier ;
  • quelques points de montage spécifiques en RAM (tmpfs) pour limiter les écritures intempestives (voir plus bas).

Toutes ces modifications se font dans le fichier etc/fstab de la partition /dev/sda1, à éditer « en tant que root » bien sûr.

Aux lignes / et /home, j’ajoute noatime,discard aux options, ce qui donne quelque chose comme :

UUID=<XYZ> /        ext4    errors=remount-ro,noatime,discard 0    1
UUID=<XYZ> /home    ext4    defaults,noatime,discard          0    2

Et j’ajoute les lignes suivantes :

tmpfs /tmp tmpfs defaults,size=256M 0 0
tmpfs /home/sebastien/.cache tmpfs defaults,size=1G 0 0
tmpfs /var/cache/apt/archives tmpfs defaults,size=2G 0 0
tmpfs /var/log tmpfs defaults,size=128M 0 0

Explications :

  • /tmp est utilisé, comme son nom l’indique, pour des fichiers temporaires ; ceux-cis sont généralement petits, par expérience je me suis rendu compte que, avec mon usage à moi, 256 Mo sont suffisants pour /tmp ;
  • /home/sebastien/.cache contient par exemple les caches des images pour le navigateur de fichiers. Ce cache permet de ne pas avoir à régénérer, encore et encore, les aperçus des images ; ou alors de ne pas avoir à retélécharger certains éléments sur Internet ; par contre, ce sont des données très variables, on peut alors limiter leur écriture sur le disque avec un cache en RAM ; d’expérience, 1 Go est largement suffisant : sur un PC « normal » en fonctionnement depuis 6 mois, ce répertoire contient environ 600 Mo de données ;
  • /var/cache/apt/archives contient les paquets téléchargés (installés ou mis à jour), qui ne sont plus nécessaires après installation dans la plupart des cas, 2 Go car s’il y a de grosses mises à jour il faut pouvoir les encaisser ;
  • /var/log contient les journaux du système ; sur un PC personnel qui fonctionne normalement, ces journaux ne sont pas très utiles, les conserver entre deux démarrages est encore moins nécessaire, ce répertoire utilise à peine 5 Mo sur un PC qui réinstallé il y a 6 mois, 128 Mo sont déjà de trop.

Notons qu’avec tmpfs, tout espace inutilisé dans le système de fichiers reste inutilisé dans la RAM : si 128 Mo sont alloués à /var/log mais que seulement 2 Mo sont utilisés, alors les 126 Mo restants sont toujours utilisables par les logiciels, ils ne sont pas réservés à ce stockage.

Avec tout ça, je minimise les écritures sur ce disque SSD, technologie supportant moins de cycles d’écriture que les disques durs mécaniques…

Source : http://doc.ubuntu-fr.org/ssd_solid_state_drive

Sur le même sujet

comments powered by Disqus