Présentation des disques électroniques SSD

Les disques électroniques SSD sont constitués de mémoire flash, ils sont plus rapides et plus résistants mais leurs cycles d'écriture sont limités. Afin d'allonger leur durée de vie vous pouvez optimiser Ubuntu pour l'usage d'un disque SSD. Du fait de l'évolution du noyau Linux et des systèmes de fichiers nombres des optimisations décrites sur cette page ne sont plus nécessaires, lorsque c'est le cas une note le spécifie.

Les disques SSD (pour Solid State Drive) représentent les unités de stockages destinées à remplacer nos traditionnels disques durs (HDD pour Hard Disk Drive). Ils sont basés sur la mémoire Flash en lieu et place des plateaux magnétiques. C'est dans les cellules des puces de mémoire Flash que l'on lit et écrit les données. Afin de réaliser ces opérations, un contrôleur dédié intégré au disque SSD reçoit les requêtes et les traite, épaulé ou non suivant les modèles par de la mémoire cache.

Les avantages de cette technologie sont :

• l'absence d'usure mécanique puisqu'aucune pièce n'est en mouvement, ce qui induit l'insensibilité (relative certes) aux chocs et un total silence de fonctionnement,
• des débits au-dessus des meilleurs disques durs, surtout pour les dernières génération de disque SSD qui accrochent les 220 Mio/s en lecture séquentielle, et flirtent avec les 200 Mio/s en écriture séquentielle (on est proche du Gio/s pour les disques SSD professionnels sur carte PCI-Express). Ces débits sont nettement inférieurs en lecture ou écriture aléatoire, mais toujours nettement au dessus des débits dans les même conditions des disques durs,
• des temps d'accès nettement inférieurs à ceux des disques durs, puisqu'on parle généralement de temps compris entre 0.2 et 0.1 ms, voire moins, là où les disques durs se situent entre 5 ms (15000 trs/min SAS) et 15 ms (7200 trs/min SATA),
• une consommation électrique un peu inférieure aux disques durs (2,5" et 3,5" mais pas 1,8"), avec à la clé un dégagement thermique plus faible et une autonomie plus grande pour les portables (même s'il faut noter que le disque dur n'est pas l'élément le plus gourmand en énergie),
• l'insensibilité à la fragmentation des système de fichiers puisque, contrairement aux disques durs, l'éloignement physique des données ne limite plus le temps d'accès.

Néanmoins, les disques SSD n'ont pas que des avantages, et on peut leur reprocher :

• une durée de vie limitée par le nombre de cycles lecture/écriture auxquels sont soumises les puces mémoire. Ce problème, très gênant pour les premières générations de disques SSD, a été en gros résolu avec la mise en place de mécanismes d'égalisation de l'usure dans les contrôleurs internes, de sorte qu'Intel revendique une durée de vie de 5 ans avec des transferts de 20 Gio de données par jour, ce qui semble largement suffisant,
• des capacités de stockage plus faibles que celles des disques durs, même si cela tend petit à petit à s'améliorer,
• et inversement un prix au Go largement plus élevé que celui des disques durs (40 fois plus cher fin 2010; 5 fois plus cher en 2012).

Les caractéristiques principales d'un disque SSD, en dehors de sa taille, sont :

• le type de cellules mémoire utilisées : on distingue les SLC (Single Level Cell) et les MLC (Multi Level Cell). En résumé, les puces SLC sont plus rapides, ont une meilleure durée de vie mais sont également beaucoup plus chères que les MLC. Ainsi, les SLC sont réservées aux disques SSD très haut de gamme, de faible capacité, tandis que la plupart des disques SSD abordables de capacité importante utilisent des puces MLC ;
• le contrôleur : c'est une pièce maîtresse du disque SSD, car c'est lui qui détermine les performances, en termes de débit et de durée de vie. Les premières générations de contrôleurs (JMicron JM601 ou JM602) sont à éviter absolument. Les contrôleurs Indilinx, Intel, SandForce ou Samsung offrent quant à eux des performances stables et satisfaisantes;
• la prise en charge du TRIM : le TRIM est une technologie permettant d'améliorer les performances des disques SSD. En effet, les disques SSD ont tendance à voir leurs performances baisser au fur et à mesure qu'on les utilise, en raison d'une forme de fragmentation des données à l'échelle du bloc mémoire (~1 Mio). Le TRIM tend à réduire, voire supprimer, cette baisse de performance, en notifiant le disque SSD de la libération des blocs mémoire. Le TRIM doit être supporté par le disque SSD et par le système d'exploitation. Les disques SSD récents à base de jeux de puces Indilinx ou SandForce ainsi que les disques SSD Intel prennent en charge le TRIM. Le noyau 2.6.33 permet d'appliquer le TRIM à la volée avec notamment Ext4, Btrfs, FAT, GFS2 et XFS, moyennant un montage des partitions accompagné de l'option "discard". Pour les autres cas (ext3, noyau antérieur au 2.6.33), il faudra passer par un script manuel qui permet d'appliquer le TRIM de ces partitions une à une. Ce script est disponible ici

Même si l'alignement des partitions n'est pas spécifique aux disques SSD, il n'a que très peu d'importance sur un disque dur traditionnel, sauf dans le cas des volumes RAID5. L'alignement consiste à faire correspondre les blocs logiques des partitions avec les blocs physiques du disque SSD pour améliorer les performances de celui-ci afin de limiter les opérations de lecture et d'écriture. L'alignement des partitions fait l'objet d'un paragraphe à part dans la section suivante.

C'est une technique utilisé par les contrôleurs des disques SSD. Elle consiste à répartir l'usure des puces mémoires en écrivant le moins souvent possible dans les même cellules, et en profitant ainsi au maximum du nombre de cycles de lecture-écriture de chacune des cellules. De ce fait, avec un bon algorithme d'égalisation de l'usure, on arrive à faire en sorte qu'un disque SSD ait une durée de vie de l'ordre de plusieurs années.

→ Plus d'informations sur Wikipédia

C'est un mécanisme visant à réorganiser la table d'allocation à la volée, ce qui permet de conserver un bon niveau lors d'écritures séquentielles sur une zone précédemment écrite de manière aléatoire. Avantage : on récupère les performances d'origine du disque SSD en écriture séquentielle ou presque. Inconvénient : on génère de nombreuses écritures dans les puces mémoire, ce qui a tendance à réduire la durée de vie du disque SSD, et, travaillant en interne, il ne libère pas les pages de Flash comme le fait le TRIM, ce qui n'est efficace que pour les écritures séquentielles, sans améliorer les écritures aléatoires. Tous les disques SSD semblent utiliser ce procédé, de manière plus ou moins agressive, et ce à la volée ou en tâche de fond (on parle alors de ramasse-miettes de fond "background garbage collection") en fonction de l'objectif du fabricant.

Le contrôleur d'un disque SSD gère la mémoire par blocs, généralement de 1 Mio. Cela sert à plusieurs choses : d'une part, les accès mémoire se font généralement par blocs pour améliorer les performances, et d'autre part, ces blocs sont régulièrement permutés pour prolonger la durée de vie du disque. Pour de bonnes performances, il est préférable que le début de partitions coïncide avec le début des blocs. On appelle ceci l'alignement.

Par défaut, lors du formatage d'un disque, Ubuntu détecte qu'il s'agit d'un disque SSD et aligne les partitions automatiquement (y compris en partitionnement manuel).

Si vous voulez en être sûr, tapez

sudo fdisk -lu /dev/sda

vous obtiendrez

Disque /dev/sda: ---- Go, -------------- octets
--- têtes, -- secteurs/piste, ------ cylindres, total ------- secteurs
Unités = secteurs de 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : ----------

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sda1            XXXX        YYYY       ZZZZ     83  Linux

Vous pouvez alors vérifier que le début de chaque partition ("XXXX") est un multiple de 2048 (secteurs). Comme un secteur fait 512 octets, et que 2048 × 512 = 1 Mio, votre disque SSD est aligné !

Ceci est vrai sur un disque dur vierge mais n'a pas l'air de fonctionner si on installe Ubuntu à la suite de Windows sur le disque. Si des partitions sont déjà présentes, il faut passer à la méthode manuelle ci-dessous." À confirmer.

Si vous souhaitez aller plus loin, vous pouvez optimiser Ubuntu pour votre disque SSD.

Cette méthode semble donner de bons résultats.

Pour Ubuntu, il faut démarrer une session Live. Une fois connecté, en console, on se servira de parted. On se retrouve donc sur l'invite de parted, première vérification : la version du disque SSD :

(parted) print
Model: ATA INTEL SSDSA2M040 (scsi)
Disk /dev/sda: 40,0GB
Sector size (logical/physical): 512B/512B

Ici, mettre à jour le micrologiciel si besoin est pour profiter de toutes les avancées technologiques de votre disque SSD. Vous trouverez la documentation nécessaire sur le site du fabricant. La taille d'un bloc, étant d'un multiple de 1024 kio, et un secteur représentant 512 octets, on en déduit que chaque bloc est composé de 2048 secteurs (1024 kio ÷ 512 octets). On va donc aligner les partitions en comptant le nombre de secteur, de manière à ce que chaque début de partition tombe sur un multiple de 2048, soit un début de bloc. D'autre part, afin de tenir compte du premier secteur réservé par le MBR, on va volontairement décaler la première partition jusqu'au premier secteur multiple de 2048. Cela ne gâche qu'un seul Mio et permet de rester aligné quoi qu'il arrive.

(parted) /dev/sda mklabel msdos

Commençons par déterminer quel est le dernier secteur du disque SSD, en changeant d'abord l'unité utilisée pour afficher les informations du disque SSD (l'unité devient le secteur) :

(parted) unit s
(parted) print free
Number  Start  End        Size       Type  File system  Flags
        63s    78165359s  78165297s        Free Space

A l'aide d'un petit tableau sous Calc (que vous pouvez téléchargerici), on calcule, à partir de la taille souhaitée de mes partitions, le secteur de début et de fin de chacune de mes partitions en suivant la règle suivante : Taille de la partition en secteurs = taille de la partition en Mo * 1024 * 1024 / 512. Une partition est donc définie par son secteur de début et son secteur de fin, ce dernier étant le secteur de début + la taille de la partition en secteur - 1 (on retranche 1 pour tenir compte du secteur du début). La partition suivante commence au secteur suivant qui sera forcément, grâce à la méthode de calcul, un multiple de 2048. Du coup, on déduit le tableau suivant :

Du coup, dans parted, il devient très simple de créer ses partitions à partir des infos calculées :

(parted) mkpart primary 2048 17205247
(parted) mkpart primary 17205248 17729535
(parted) mkpart primary 17729536 78145535

On peut vérifier le résultat une fois les partitions créées :

(parted) print
Number  Start           End             Size            Type     File System    Flags
 1      2048s           17205247s       17203199s       primary
 2      17205248s       17729535s         524287s       primary
 3      17729536s       78145535s       60415999s       primary

Si on affiche à nouveau les informations avec l'octet comme unité, on peut vérifier la taille des partitions de manière plus parlante :

(parted) unit MB                 //ou unit GB
(parted) print
Number  Start           End             Size            Type     File System    Flags
1       1,05MB          xxxxMB          xxxxMB          primary
2       xxxxMB          xxxxMB          xxxxMB          primary
3       xxxxMB          xxxxMB          xxxxMB          primary

Il ne reste plus qu'à placer le drapeau de boot sur la première partition pour s'assurer du bon fonctionnement du bootloader et du chargement du futur SE :

(parted) set
1
boot
on

Le résultat en vérification :

Number  Start           End             Size            Type    File System     Flags
1       0,00GB          8,40GB          8,40GB          primary                 boot

Il faut maintenant créer les système de fichiers. Ici, on passera par ext4, que l'on montera ensuite avec l'option noatime pour ne pas provoquer d'écriture lors d'une simple lecture. Là encore, on se sert des options de formatage du système de fichiers ext4 pour aligner la partition. Il faut aligner la partition avec des blocs logique de 4 Ko (4096 o), et un stride respectant l'alignement des blocs physique du disque SSD. Les blocs logiques font 4 Ko, on sait que les blocs physique font 128 Ko, on aura donc un stride de 32 (128 Ko / 4 Ko). Cette histoire de stride n'est pas claire, mais l'utilisation de ces deux valeurs permet visiblement de tout aligner correctement. On créé donc les systèmes de fichiers ext4 sur les partitions adéquat :

mkfs.ext4 -b 4096 -E stride=32 /dev/sda1
mkfs.ext4 -b 4096 -E stride=32 /dev/sda3
mkfs.ext4 -b 4096 -E stride=32 /dev/sda4

Si vous souhaitez utiliser ReiserFS, il est possible de formater vos partitions en forçant la taille des blocs logique, mais pas le stride. Ne sachant pas quelle est l'influence de ce paramètre, je ne sais pas si cela va réellement dégrader les performances ou pas, mais a priori, cela reste négligeable voir même inexistant :

mkreiserfs -b 4096 /dev/sda1

Même si au final on ne monte pas forcement cette partition (ou alors on en minimise l'accès), Ubuntu impose d'avoir une partition d'échange au moment de l'installation, donc autant que cette dernière soit également alignée. Ensuite, lors de l'installation, on définit les point de montage, mais on ne les formate pas. Il le sont déjà, et un nouveau formatage ne réutiliserait pas forcément les valeurs de bloc et de stride que l'on a utilisé, ruinant alors l'alignement.

Avec cette méthode, on ne change que la façon de compter les partitions, mais pas celle de compter les blocs. Ainsi, on gardera les même partitions que dans la méthode précédente, avec les même secteurs de début et de fin, mais on utilise une autre façon de créer les partitions.

Le problème de la méthode précédente est qu'elle se limite à 4 partitions, puisque les tables de partitions standards se limitent à 4 partitions primaires. Une autre solution consisterait à ne créer qu'une partition étendue sur l'intégralité du disque dur, et de tailler ses lecteurs logiques dedans. Néanmoins, il existe une autre façon de créer ses partitions : utiliser une table de partition de type GPT. Avec ce type de table, qu'on pourrait qualifier de "moderne", la nuance entre partition principale et étendue n'existe plus, toute les partitions étant du même type, et il n'y a plus de limite au nombre de partitions que l'on peut créer sur un disque.

Ceci mis au clair, on peut partitionner le disque, toujours avec Parted. Pour cela, une fois parted lancé, on commence par créer la table GTP (c'est à ce moment que toutes les partitions antérieures et les données qu'elles contenaient deviendront inaccessibles) :

(parted) mklabel
Nouveau type d'étiquette de disque ? gpt

On change l'unité de parted pour le secteur :

(parted) unit s
(parted) print free
Number    Start     End           Size          Type   File        System Flags
          0s        50069679s     250069680s           Free Space

Ensuite, on créé les partitions en utilisant les secteurs trouvés par les calculs de la méthode précédente, en donnant à chaque partition l'étiquette qui correspond au type de données qu'elles vont recevoir :

(parted) mkpart linux_root 256 17203455
(parted) mkpart linux_swap 17203456 17727743
(parted) mkpart linux_home 17727744 27967743
(parted) mkpart linux_datas 27967744 250069679

Les partitions créées, on reprendra la méthode précédente pour la création des systèmes de fichiers, les règles sur la taille de bloc et de stride pour les volumes ext4 semblant toujours d'actualité avec ce type de partitionnement.

Le choix du système de fichiers pour un disque SSD est problématique. En effet, comme on l'a dit précédemment, on cherche à éviter au maximum les écritures inutiles sur un disque SSD pour en préserver au maximum la durée de vie. Dans le même temps, les systèmes de fichiers modernes sont tous journalisés, c'est-à-dire qu'ils stockent de nombreuses informations sur les accès aux fichiers, ce qui génère de nombreuses écritures mais garantit également dans une certaine mesure la sécurité des données en cas de plantage du système. On se trouve donc devant un conflit d'intérêt.

On compte parmi ces systèmes de fichiers JFFS2, LogFS ou UBIFS. Ils incorporent des optimisations permettant de limiter les E/S, et pour certains de journaliser. En revanche, il s'avère que dans le cas des disques SSD, ils ne sont pas spécialement adaptés car les disques SSD intègrent désormais au niveau du contrôleur des algorithmes effectuant déjà les optimisations susceptibles d'être utiles dans ces systèmes de fichiers. Le travail serait donc réalisé deux fois, ce qui est inutile. Pire, cela induirait dans certains cas des latences qui peuvent ralentir le système. En attendant Btrfs, ces systèmes de fichiers sont donc à exclure pour l'utilisation d'un disque SSD.

La première solution consiste à utiliser un système de fichiers non journalisé, c'est-à-dire concrètement ext2 ou ext4 sans journal. Ces systèmes de fichiers ne génèrent pas d'écriture particulière en dehors des sauvegardes de données explicites. Ils auront donc tendance à économiser un disque SSD. Néanmoins, le risque de perte de données en cas de plantage est réel, et il faut donc l'utiliser en connaissance de cause.

• Pour savoir si une partition ext4 est journalisée, il faut regarder si le drapeau has_journal est présent avec la commande suivante en remplaçant sda1 par l'identifiant de votre partition (sda2, hdb1, …) :

sudo tune2fs -l /dev/sda1 | grep feature
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

• Pour passer d'une partition journalisée à une partition non journalisée, il suffit de "supprimer la journalisation et de reconstruire la partition" (termes à préciser) en remplaçant sda1 par l'identifiant de votre partition (sda2, hdb1, …) :

sudo tune2fs -O^has_journal /dev/sda1
sudo e2fsck -f -v -C0 /dev/sda1

Comme dit plus tôt, le principal intérêt des systèmes de fichiers journalisés est de garantir une (relative) sécurité des données en cas de plantage du système ou d'extinction brutale de la machine. La journalisation entrant en conflit avec la durée de vie des disque SSD, il est difficile de faire un choix. Néanmoins, ce qui ressort des discussions sur la toile et des déclarations des fabricants autant que des sites spécialisés est que l'égalisation de l'usure permet de s'affranchir de ce problème, en gérant directement au niveau du contrôleur l'usure des puces mémoire. L'utilisation des systèmes de fichiers ext3, ext4 ou ReiserFS est envisageable sur les disques SSD assez récents, qui incorporent une bonne gestion de l'égalisation de l'usure. On pourra néanmoins améliorer la gestion de la journalisation en se servant des options de montage des partitions journalisées, comme on le verra dans la partie III. À noter néanmoins que ext4 est l'étape précédant Btrfs, système de fichiers qui devrait inclure des optimisation spéciales pour les disques SSD. On peut donc imaginer que ext4 incorpore déjà une partie de ces optimisations, et qu'il est préférable à ext3 dans le cadre de l'utilisation d'un système de fichiers journalisé sur un disque SSD. Pour finir, on soulignera que seul ext4 supporte le TRIM à la volée pour les disque SSD qui le permettent (voir le paragraphe sur le TRIM).

Des doutes existent quant à la durée de vie des mémoires SSD par rapport aux disques durs. Bien qu'il n'y ait pas d'étude claire sur la question, les sections suivantes expliquent comment minimiser les accès en écriture du disque SSD.

Les optimisations des points 4.2 à 4.6 sont réservées aux ordinateurs ayant plus de 512 Mio de mémoire vive (RAM).

Utilisez l'option noatime pour éviter d'écrire sur le disque la date du dernier accès en lecture lorsqu'il n'y a pas d'écriture.

Vous pouvez vérifier que vos partitions sont montées avec cette option en ouvrant le ficher /etc/fstab (avec les droits d'administration), dans lequel vous trouvez des lignes telles que :

UUID=57480a3f-e7db-4a5e-9fca-7df45f5a7d9d /               ext4    defaults,noatime,errors=remount-ro 0       1

Si noatime n'est pas indiqué après defaults, vous pouvez le rajouter (séparé par une virgule).

Le système utilise un certains nombre de fichiers temporaires, qu'il n'est pas nécessaire de conserver d'un démarrage à l'autre. Il est ainsi possible de les placer dans la mémoire vive (qui est vidée à l'arrêt de l'ordinateur) au lieu de les avoir sur le disque SSD.

Cependant, certains logiciels (tels que l'environnement de bureau KDE) utilisent un grand nombre de fichiers temporaires, et devront alors les recréer, ce qui peut ralentir le démarrage si vous utilisez ces logiciels.

Pour mettre les fichiers temporaires en mémoire vive (par exemple, pour une taille maximum de 1 Gio), ouvrez le ficher /etc/fstab (avec les droits d'administration) et ajoutez-y la ligne suivante :

tmpfs      /tmp            tmpfs        defaults,size=1g           0    0

Même technique que pour ci dessus, il suffit de remplacer le chemin /tmp par /home/nomd'utilisateur/.cache

Ce qui donne :

tmpfs    /home/nomd'utilisateur/.cache    tmpfs    defaults,size=1g    0    0

Vu les temps d'accès des SSD, il est inutile de conserver ces derniers indéfiniment.

Vous pouvez ajouter autant de dossiers que vous souhaitez en mémoire vive, contrairement à windows et ses ramdisks réclament immédiatement la mémoire allouée sur la mémoire vive, ici son utilisation est dynamique, ne sera donc utilisé que ce qui est utilisé par les dossiers ciblés.

Avant l'opération, pensez à supprimer le contenu du dossier .cache de votre dossier personnel.

Encore une fois, même technique que précédemment, il suffit de remplacer le chemin /tmp par /var/cache/apt/archives , mais il est toutefois conseillé de disposer d'au moins 6Go de mémoire vive pour cette opération

tmpfs    /var/cache/apt/archives    tmpfs    defaults,size=4g    0    0

Avant le prochain redémarrage, il faut également vider le cache d'apt, via cette commande :

sudo apt-get clean

Cette opération a cependant un défaut majeur, en cas d'impossibilité pour votre machine, d'accéder à internet, vous ne pourrez pas installer les paquets qui seraient restés indéfiniment dans le cache lors d'un redémarrage. Par contre, sachant que tous les fichiers dont téléchargés en mémoire vive, votre système pourra installer des logiciels et se mettre à jour plus vite, tant par le débit en lecture de la mémoire vive, que le fait de soulager le SSD en lecture, permettant ainsi un débit optimal en écriture. Enfin évidemment, vu la fréquence d'apparitions de mises à jour, autant économiser la durée de vie du SSD au maximum.

Il est possible de ne pas créer de partition d'échange SWAP durant l'installation d'Ubuntu en définissant les partitions manuellement (avancé). Cela permet de forcer l'utilisation de la mémoire vive et d'économiser l'espace qu'aurait pris cette partition sur le disque dur !

Si vous avez créé une partition d'échange SWAP (notamment pour bénéficier de l'hibernation), mais que vous souhaitez en minimiser l'usage, ouvrez le ficher /etc/sysctl.conf (avec les droits d'administration) et ajoutez à la fin :

vm.swappiness=0

Cette manipulation indique à Ubuntu de n'utiliser la partition d'échange qu'en dernier recours quand votre mémoire vive est pleine ! (« 1 » indique de l'utiliser lorsqu'il ne reste que 1 % de disponible en mémoire vive, « 2 » quand il reste 2 %, etc.).

RESUME=UUID=votre uuid de la partition d'échange

sudo update-initramfs -u

Pour que Firefox place son cache dans le répertoire /tmp (mémoire vive). Taper about:config dans Firefox et créer une nouvelle chaîne de caractères que vous nommerez browser.cache.disk.parent_directory et entrez dans la case /tmp.

Si votre machine dispose d'une connexion suffisamment rapide, on peut désactiver complètement le cache persistant en modifiant l'option browser.cache.disk.enable avec la valeur false.

• Déplacer son répertoire usr
• Déplacer son répertoire home

Sous Linux, il y a une quantité impressionnante de fichiers logs (journaux d'activité) générés par le système, les dæmons, des processus divers et des applications. Rien que le dæmon principal du système (rsyslogd) écrit dans pas moins d'une dizaine de fichiers de log et cela en continu ! Tous ces fichiers n'ont aucune incidence sur le système ou les applications – ce ne sont que des rapports d'activité de processus internes – et de surcroît ils n'ont pas d'intérêt particulier pour l'utilisateur lambda. Tout au plus un administrateur système ou un administrateur de serveur peut-il parfois avoir besoin d'aller consulter certains de ces logs pour, par exemple, voir quel utilisateur s'est connecté quand et combien de temps, ou quel appareil USB a été introduit dans quel port. En plus, tous ces fichiers sont gardés et compactés en archives gzip une fois une certaine taille atteinte (cela constitue un historique de ces rapports sur de très longues périodes).

On peut monter ce répertoire en mémoire vive au démarrage.

• Avantage : diminution considérable d'écritures inutiles faites en continu sur le disque SSD
• Inconvénient : tous les logs seront perdus à chaque redémarrage (plus d'historique dans le temps)

C'est une manipulation simple, semblable au déplacement des fichiers temporaires en mémoire vive décrite plus haut : il suffit d'éditer (en mode admin) le fichier /etc/fstab pour rajouter à la fin :

tmpfs /var/log tmpfs defaults,nosuid,nodev,noatime,mode=0755,size=5% 0 0

Après un redémarrage, tous ces fichiers de journalisation seront écrits dans un répertoire temporaire en mémoire vive et perdus à l'arrêt du système.

Ce mécanisme de réarrangement des IOCTL a pour objet d'optimiser les commandes I/O vers le disque dur ATA/SATA en prenant en compte la nature du disque dur en question et certaines contraintes en découlant. Il y a trois différentes options : cfq, noop et deadline. Par défaut dans Ubuntu, l'option "cfq" est utilisée car elle convient bien aux disques durs traditionnels, en réorganisant la file des commandes I/O en fonction des temps de rotation des plateaux et des délais de "seek" des têtes. Vous pouvez vérifier quel ordonnanceur d'E/S est utilisé par votre système dans un terminal comme ceci :

cat /sys/block/sda/queue/scheduler

Vous obtenez quelque chose comme cela :

noop deadline [cfq]

où l'ordonnanceur présentement utilisé est indiqué entre des crochets.

La meilleure option qui optimise les E/S pour la rapidité des temps d'accès des disques SSD est "deadline". Si cela n'est pas le cas (autre résultat obtenu avec la commande cat /sys/block/sda/queue/scheduler) il existe une manière simple de déclarer cette option "deadline" de façon permanente en la passant directement dans les paramètres donnés au noyau lors du démarrage.

Ouvrez le fichier menu.lst de GRUB (dans /boot/grub) en mode administrateur et rajouter dans chaque ligne de noyau la mention elevator=deadline dans la partie des paramètres comme ceci :

title		Ubuntu 10.10, kernel 2.6.35-25-generic
uuid		f0d9c48e-00c4-4225-ab21-1c5a42194bc8
kernel		/boot/vmlinuz-2.6.35-25-generic root=UUID=f0d9c48e-00c4-4225-ab21-1c5a42194bc8 ro quiet splash 
initrd		/boot/initrd.img-2.6.35-25-generic

title		Ubuntu 10.10, kernel 2.6.35-25-generic (recovery mode)
uuid		f0d9c48e-00c4-4225-ab21-1c5a42194bc8
kernel		/boot/vmlinuz-2.6.35-25-generic root=UUID=f0d9c48e-00c4-4225-ab21-1c5a42194bc8 ro single
initrd		/boot/initrd.img-2.6.35-25-generic

title		Ubuntu 10.10, memtest86+
uuid		f0d9c48e-00c4-4225-ab21-1c5a42194bc8
kernel		/boot/memtest86+.bin
quiet

devient :

title		Ubuntu 10.10, kernel 2.6.35-25-generic
uuid		f0d9c48e-00c4-4225-ab21-1c5a42194bc8
kernel		/boot/vmlinuz-2.6.35-25-generic root=UUID=f0d9c48e-00c4-4225-ab21-1c5a42194bc8 elevator=deadline ro quiet splash 
initrd		/boot/initrd.img-2.6.35-25-generic

title		Ubuntu 10.10, kernel 2.6.35-25-generic (recovery mode)
uuid		f0d9c48e-00c4-4225-ab21-1c5a42194bc8
kernel		/boot/vmlinuz-2.6.35-25-generic root=UUID=f0d9c48e-00c4-4225-ab21-1c5a42194bc8 elevator=dealdline ro single
initrd		/boot/initrd.img-2.6.35-25-generic

title		Ubuntu 10.10, memtest86+
uuid		f0d9c48e-00c4-4225-ab21-1c5a42194bc8
kernel		/boot/memtest86+.bin
quiet

Sauvegardez le fichier menu.lst ainsi modifié et redémarrez.

Au prochain redémarrage, vous pourrez constater que l'ordonnanceur d'E/S a changé pour "deadline" (dans un terminal) :

cat /sys/block/sda/queue/scheduler
noop [deadline] cfq 

Il faut modifier le fichier /etc/default/grub avec les droits d'administrateur et rajouter "elevator=deadline" à la ligne d'options :

GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline quiet splash"

puis mettre à jour grub pour que les modifications soient passées à grub.cfg :

sudo update-grub

→ Référence

Comme mentionné plus haut, les disques SSD voient leurs performances diminuer à mesure que les cellules (bloc mémoire) se remplissent - même partiellement; et cela induit des performances en écriture de plus en plus médiocres à mesure que le disque SSD vieillit et qu'il y a de moins en moins de cellules vierges disponibles. Ce phénomène est dû à la manière dont le disque SSD fonctionne en écriture au niveau des cellules de mémoire flash : si une cellule est vierge, le contrôleur peut directement écrire dedans - par contre si elle contient déjà des données (même 1 seul bloc d'allocation de 4k alors que la cellule contient 1024k au total), le contrôleur doit lire la cellule + la remettre à zéro + écrire les données - une opération beaucoup plus lente. Pour la plupart des disques SSD récents, la commande "Trim" (disponible notamment pour ext4, Btrfs, FAT, GFS2 et XFS) permet à Ubuntu (à partir du noyau 2.6.33) d'éviter que les performances ne se dégradent avec le temps. Elle sert à notifier le disque SSD lors de l'effacement d'un fichier. Le contrôleur du disque SSD peut alors effacer les cellules de mémoire flash anciennement utilisées afin d'optimiser les écritures ultérieures qui pourront alors être effectuées sans avoir à réaliser l'effacement préalable imposé par la technologie de la mémoire flash, charge étant au contrôleur de remettre à zéro les cellules qui peuvent l'être et ainsi augmenter les cellules vierges disponibles. Vous pouvez vérifier cela en mode terminal :

sudo hdparm -I /dev/sda

qui liste tous les paramètres et fonctionnalités du disque SSD. Dans le paragraphe "Commands/features" une ligne doit clairement indiquer le support TRIM. Il existe plusieurs mécanismes de Trim des disques SSD :

De loin la solution la plus facile et la plus souple. Il suffit alors d'éditer son fichier /etc/fstab (en mode administrateur) et de rajouter l'option discard dans les lignes correspondant au montage des volumes en ext4

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda1
UUID=f0d9c48e-00c4-4225-ab21-1c5a42194bc8 /               ext4    noatime,errors=remount-ro 0       1
# /dev/sda2
UUID=43e974d7-82d9-43b1-b67b-5233b18f056e none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0

devient

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda1
UUID=f0d9c48e-00c4-4225-ab21-1c5a42194bc8 /               ext4    noatime,discard,errors=remount-ro 0       1
# /dev/sda2
UUID=43e974d7-82d9-43b1-b67b-5233b18f056e none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0

Ensuite les commandes de TRIM sont directement passées au contrôleur du disque SSD par le noyau, de façon entièrement transparente.

À priori, cette méthode n'est nécessaire que dans le cas d'une partition principale en ext3 ou d'un noyau inférieur à 2.6.33. Il est conseillé d'effectuer un trim manuel environ une fois par mois pour une utilisation normale du disque SSD. On ne peut pas lancer un TRIM en manuel sur une partition montée (donc pas non plus sur la partition de démarrage). Il faudra donc démarrer sur un live-usb ou un disque dur externe (cd-rom déconseillé). La procédure indiquée ci-dessous utilise une clé Live-usb faite à partir de l'image d'un cd d'installation Ubuntu Desktop. La méthode utilise le script wiper.sh qui est distribué en standard avec le paquet hdparm. Il faut au minimum une version v9.28 ou plus élévée de hdparm. On peut vérifier la version dans un terminal :

 ~$ sudo hdparm -V

D'autre part, il est fortement conseillé d'utiliser les sources les plus récentes de hdparm (il y a moins de bugs et de problèmes avec ces commandes nouvelles et complexes); ce qui implique malheureusement de télécharger et recompiler les sources du paquet hdparm (que l'on peut obtenir ici).

Procédure :

• télécharger la dernière version des sources hdparm
• décompresser l'archive
• copier le dossier dans la clé usb Live-boot au premier niveau
• insérer la clé Live-usb et booter en live sans installer Ubuntu
• aller dans dossier contenant hdparm (avec cette clé, le volume / est monté dans /cdrom)

  cd /cdrom/hdparm[tab]

• compiler et installer
• aller dans le dossier wiper

  ~$cd wiper

• déclencher un simulation de TRIM sur la partition visée

  sudo ./wiper.sh /dev/sda1

• si la simulation se passe bien, effectuer réellement le TRIM en rajoutant l'option --commit

  sudo ./wiper.sh --commit /dev/sda1

Si tout se passe bien, vous devriez pouvoir rebooter sur votre partition principale Linux. Il faut malheureusement recompiler et réinstaller hdparm à chaque démarrage sur la clé USB (à moins d'avoir une clé Live persistante).

→ Plus d'informations sur l'utilisation de « hdparm »

Un des avantages de la méthode hdparm/wiper.sh décrite ci-dessus est que l'on peut effectuer le trim d'un volume NTFS. Ce qui est très utile dans le cas d'un système à double démarrage Linux/Windows avec une version XP ou Vista installée dans le volume NTFS (Windows 7 prend en charge le TRIM à la volée en standard). C'est plus facile à faire sur un volume NTFS, car il n'y a pas besoin d'utiliser un Live-usb pour libérer la partition Linux. Il suffit que le volume NTFS soit hors ligne (non monté).

Il est quand même conseillé de télécharger, recompiler et installer la dernière version des sources hdparm dans votre volume / et elle sera ensuite disponible de façon permanente.

Procédure :

• télécharger et compiler la dernière version des sources hdparm, puis installer
• faire une sauvegarde ou un clone de votre partition NTFS - on ne sait jamais…
• dans un terminal, aller dans le dossier qui contient hdparm, puis dans le sous-dossier wiper
• vérifier que votre partition NTFS est bien démontée et repérer le No de partition
• faire une simulation de TRIM sur la partition NTFS (dans cet exemple elle se trouve sur sda3)

  sudo ./wiper.sh /dev/sda3

• si tout se passe bien, effectuer le TRIM pour de vrai en rajoutant --commit

  sudo ./wiper.sh /dev/sda3 --commit

Modification faite le 24/12/2011 La version 3.3 de Wiper fournie avec HDPARM-9.37 réserve une surprise possible pour certains formats NTFS . Explication dans le source lignes 657 et 358

       ## This is where we finally discover whether the filesystem actually
       ## supports --fallocate or not.  Some folks will be disappointed here.

qui survient lorsque la partition n'a pas été démontée correctement.

C'est une autre méthode brutale d'optimisation qui s'adresse principalement aux utilisateurs qui ne voudraient pas utiliser la méthode de TRIM manuel, ou bien qui auraient des difficultés à recompiler les sources hdparm, ou encore dont le disque SSD ne supporterait pas la commande TRIM. Le but est d'utiliser la commande ATA Secure-Erase qui déclenche un effacement complet du disque par écriture de 00h dans tous les octets de sa surface (donc pour un disque SSD la remise à zéro effective de toutes les cellules flash).

• Avantages : plus simple que le TRIM en manuel, le disque SSD se retrouve comme à sa sortie d'usine.
• Inconvénients : clonage préalable du disque indispensable, moins efficace que le TRIM, probable manipulation hardware requise

* Remarque : Il est à craindre que le fait de restaurer une image exacte va tout remettre comme avant. Et donc annuler l'effet de la remise à zero.

Procédure :

• effectuer un clonage du disque SSD en mode disk-device vers image (pour clonezilla)
• redémarrer sur une clé Live-usb Ubuntu ou un cd d'installation Ubuntu (récents) afin que le disque SSD soit libéré
• dans un terminal vérifier si le disque SSD cible est en mode frozen ou not frozen

  sudo hdparm -I /dev/sda

  (la mention se trouve dans le dernier paragraphe Security) - si déjà en mode "non gelé", sauter les 2 lignes suivantes

• si le disque est en mode frozen (probable), il faut le retirer physiquement de l'interface, attendre quelques secondes, puis le réinsérer
• vérifier à nouveau dans les paramètres "Security" comme indiqué ci-dessus que le disque est cette fois bien en mode not frozen
• dans le terminal, taper les 2 commandes qui vont déclencher l'effacement (note : cas où le disque SSD se trouve en sda)

  sudo hdparm --security-set-pass NULL /dev/sda
  sudo hdparm --security-erase NULL /dev/sda

  l'exécution en soi ne doit prendre que quelques secondes pour un disque SSD

• restaurer l'image-disque clonée au début
• C'est fini !

Sur certains SSD (comme le corsair V4) il se peut que vous aillez des ralentissements lors d'une mise à jour (ou apt-get), pour y remédier, il suffit d'ajouter l'option

data=writeback

dans /etc/fstab. Il faut exécuter le code suivant pour le désactiver tout d'abord :

sudo tune2fs -o journal_data_writeback /dev/sda1

en remplaçant sda1 par l'identifiant de votre partition (sda2, hdb1, …) :

Ureadhead est destiné à améliorer les performances de démarrage sur les disques durs traditionnels en organisant l'ordre de lecture sur le disque. Malheureusement sur certains disques SSD très vieux il réduit aujourd'hui les performances car les programmes ne démarrent pas pendant le chargement ureadhead alors que les performances du disque SSD permettent un accès direct au données bien plus efficace lors du démarrage des programmes. Le bug LP #577763 est ouvert à ce sujet.

Un contournement pour désactiver ureadhead est de désactiver le lancement du daemon correspondant dans le script d'amorçage upstart :

• Ouvrir le fichier /etc/init/ureadahead.conf avec les droits super-utilisateurs
• Commenter la ligne exec /sbin/ureadahead –daemon en rajoutant un dièse (#) tout au début

Contributeurs : Kortex@HFR et Albator du forum.hardware.fr, un grand merci à eux