Les disques durs SSD sont constitués de mémoire flash, ils sont plus rapides et plus résistants mais leurs cycles d'écriture sont limités. Donc afin d'allonger leur durée de vie vous pouvez optimiser Ubuntu pour l'usage d'un SSD.

Les 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 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'inexistence 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 HDD, surtout pour les dernières génération de 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 SSD professionnels sur carte PCI-Express, à des prix complètement indécents). 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 HDD,
• des temps d'accès nettement inférieur à ceux des HDD, puisqu'on parle généralement de temps compris entre 0.2 et 0.1 ms, voire moins, là où les HDD se situe entre 5 ms (15000 trs/min SAS) et 15 ms (7200 trs/min SATA),
• une consommation électrique un peu inférieure aux HDD (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 HDD, l'éloignement physique des données ne limite plus le temps d'accès.

Néanmoins, les 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 SSD, a été en gros résolu avec la mise en place de mécanismes de répartition de l'usure (wear levelling) 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 HDD, même si cela tend petit à petit à s'améliorer,
• et inversement un prix au Go largement plus élevé que celui des HDD (40 fois plus cher fin 2010).

Les caractéristiques principales d'un 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 SSD très haut de gamme, de faible capacité, tandis que la plupart des SSD abordables de capacité importante utilisent des puces MLC ;
• le contrôleur : c'est une pièce maîtresse d'un 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ôleur Indilinx, Intel ou Samsung offrent quant à eux des performances stables et satisfaisantes;
• le support du TRIM : le TRIM est une technologie permettant d'améliorer les performances des SSD. En effet, les 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 SSD de la libération des blocs mémoire. Le TRIM doit être supporté par le SSD et par l'OS. Les SSD récents à base de chipset Indilinx ou SandForce ainsi que les SSD Intel supportent le TRIM. Le noyau 2.6.33 permet d'appliquer le TRIM à la volée avec ext4, moyennant un montage des partitions accompagné de l'option discard. Pour les autres cas (ext3, kernel antérieur au 2.6.33), il faudra passer par un script manuel qui permet de trimmer ses partitions une à une. Ce script est disponible ici

Même si l'alignement des partitions n'est pas spécifique aux SSD, il n'a que très peu d'importance sur un spinoff, sauf dans le cas des volumes RAID5. L'alignement consiste à faire correspondre les blocs logiques des partitions avec les blocs physiques du 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 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 de wear levelling, on arrive à faire en sorte qu'un 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 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 à amoindrir la durée de vie du SSD, et le disque travaillant en interne, il ne libère pas les pages de Flash comme le fait le TRIM, ce qui fait que cela n'est efficace que pour les écritures séquentielles, sans améliorer les écritures aléatoires. Tous les 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 background garbage collection) en fonction de l'objectif du fabricant.

Le contrôleur d'un 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 cela l'alignement.

Par défaut, lors du formatage d'un disque, Ubuntu détecte qu'il s'agit d'un 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 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 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 SSD :

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

Ici, flasher le firmware si besoin est pour profiter de toutes les avancées technologiques de votre SSD. Vous trouverez la documentation nécessaire sur le site du constructeur. La taille d'un bloc, étant d' un multiple de 1024 kio, et un secteur représentant 512 octers, 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 SSD, en changeant d'abord l'unité utilisée pour afficher les informations du 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 OS :

(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 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 de swap 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 le label 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 SSD est problématique. En effet, comme on l'a dit précédemment, on cherche à éviter au maximum les écritures inutiles sur un 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 garantie également dans une certaine mesure la sécurité des données en cas de crash du système. On se trouve donc devant un conflit d'intérêt.

On compte parmi ces système de fichiers JFFS2, LogFS ou UBIFS. Ils incorporent des optimisations permettant de limiter les entrées/sorties, et pour certains de journaliser. En revanche, il s'avère que dans le cas des SSD, ils ne sont pas spécialement adaptés car les SSD intègre désormais au niveau du contrôleur des algorithme effectuant déjà les optimisation 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 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 SSD. Néanmoins, le risque de perte de données en cas de crash est réel, et il faut donc l'utiliser en connaissance de cause.

Comme dis 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 crash du système ou d'extinction brutale de la machine. La journalisation entrant en conflit avec la durée de vie des SSD, il est difficile de faire un choix. Néanmoins, ce qui ressort des discussions sur le net et des déclarations des constructeurs autant que des sites spécialisés est que le wear-levelling 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 SSD assez récent, qui incorporent une bonne gestion du wear-levelling. 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. A noter néanmoins que ext4 est l'étape précédent BTRFS, système de fichiers qui devrait inclure des optimisation spéciales pour les 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 SSD. Pour finir, on soulignera que seul ext4 supporte le TRIM à la volée pour les 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 SSD.

Les optimisations des points 3.2 à 3.6 sont réservées aux PC 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. De même avec nodiratime pour les dossiers.

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,nodiratime,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 dans le 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

Il est possible de ne pas créer de partition 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 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 swap qu'en dernier recours quand votre RAM est pleine à craquer ! (« 1 » indique de l'utiliser lorsqu'il ne reste que 1 % de disponible en RAM, « 2 » quand il reste 2 %, etc.).

RESUME=UUID=votre uuid de la swap

sudo update-initramfs -u

Pour que Firefox place son cache dans le répertoire /tmp/firefox (RAM). 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/firefox.

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 surcroit 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 RAM au démarrage.

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

C'est une manipulation simple, semblable à la mise en RAM du répertoire « /tmp » 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 0 0

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

Il est également interessant de mettre en ram d'autre path système accedés relativement souvent. Il suffira de procéder de la même manière que pour /var/log en ajoutant au fichier /etc/fstab :

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

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 mécaniques, en réorganisant la queue 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 I/O Scheduler 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ù le scheduler présentement utilisé est indiqué entre des brackets.

L'option la meilleure, celle qui optimise les I/O pour la rapidité des temps d'accès des SSD est "deadline". Heureusement, 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 kernel lors du démarrage.

Ouvrez le fichier menu.lst de GRUB (dans /boot/grub) en mode administrateur et rajouter dans chaque ligne de kernel 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 le I/O Scheduler 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 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 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. Le Trimming a pour objet d'indiquer au contrôleur du SSD lorsque des blocs d'allocation se libèrent suite à l'effacement de fichiers par le filesystem (ce qu'il ne peut pas savoir directement à priori); et donc que ces plages libérées sont à nouveau disponibles pour écrire dessus - charge étant au contrôleur de remettre à zéro les cellules qui peuvent l'être et ainsi augmenter les cellules vierges disponibles. Bien entendu, il faut que le SSD supporte la commande TRIM afin de pouvoir réaliser cette opération (ce qui est le cas pour la plupart des SSD récent). Vous pouvez vérifier cela en mode terminal :

sudo hdparm -I /dev/sda

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

De loin la solution la plus facile et la plus souple. Pour cela il faut au minimum un noyau Linux 2.6.33 ou plus élevé et avoir formaté sa partition Linux en ext4. 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    async,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    async,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 SSD par le kernel, 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 trimming d'un volume NTFS. Ce qui est très utile dans le cas d'un système en double-boot 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 offline (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 suprise 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 « brute force » 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 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 SSD la remise à zéro effective de toutes les cellules flash).

• Avantages : plus simple que le TRIM en manuel, le 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

Procédure :

• effectuer un clonage du 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 SSD soit libéré
• dans un terminal vérifier si le 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 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 SSD

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

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 très vieux SSD il réduit aujourd'hui les performances car les programmes ne démarrent pas pendant le chargement ureadhead alors que les performances du 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