Les disques SSD c'est bien, c'est super-rapide, mais cela souffre d'un certain handicap après de nombreuses mises à jour. Le contrôleur interne du SSD essaye de répartir l'utilisation des "blocs" afin de ne pas avoir un bloc ré-écrit en permanence qui ne manquerait pas de "s'user" avant les autres.
Le contrôleur interne du SSD a donc "besoin" de connaitre les blocs libérés afin de pouvoir les ré-attribuer. Or les systèmes de gestion de fichiers de Linux, s'ils libèrent les blocs d'un fichier détruit (et enregistrent ces blocs comme "libres) n'en informent pas le contrôleur interne du SSD, celui-ci se trouve donc, au bout d'un certain temps, "à court" de blocs qu'il sait pouvoir réattribuer.
Cet état de fait est très préjudiciable à la performance (surtout en écriture) lorsque le disque a un peu vécu.
Heureusement on trouve sur Sourceforge au sein du projet "hdparm" un logiciel (wiper) qui permet de transmettre au contrôleur interne du SSD les renseignements voulus (http://sourceforge.net/projects/hdparm/files/wiper-2.6.tar.gz) qui permet de réaliser l'opération.
Le seul problème est que mon disque (OCZ Vertex) était un peu "ancien" (version firmware 1.4) et qu'il faut être au moins en 1.5). Heureusement, OCZ a publié une image ISO qui permet de réaliser cette opération délicate, on peut la trouver à (http://www.ocztechnologyforum.com/staff/ryderocz/vertex/vertex_15.zip) qu'il faut dézipper, graver en ISO. Il faut ensuite booter sur le CD avec le SSD monté, le reste est expliqué sur l'écran, attention tous les SSD Vertex (même en version 1.4) ne sont pas "capables" de recevoir cette mise à niveau (???).
Nouveauté 1: il existe sur le site une version pour SSD "récalcitrants" (avec "fail" dans le nom, j'en avais un qui refusait la mise à jour "standard", avec cette version l'affreux SSD a parfaitement été mis à jour.
Nouveauté 2 : il existe maintenant une version 1.6 du soft des SSD que je vais essayer à l'occasion.
Attention, ces manipulations peuvent entraîner une perte de données !!! Un bon backup est nécessaire !!!
Dans mon cas où il s'agissait du disque "système", j'en ai réalisé une copie conforme sur un "vieux" disque SATA (dd est un très bon ami à moi) que j'ai ensuite testé (faut que ça boote !), avant de tenter les manip : "upgrade version firmware SSD" et "wiper".
Ces manipulations devraient disparaître peu à peu en fonction de l'évolution des noyaux, (il existe des outils intégrés pour Windows 7) et le noyau Linux devrait rapidement prendre en compte cette option.
En attendant il est nécessaire de recourir à des manipulations assez peu orthodoxes. Si on peut "wiperiser" un disque démonté il n'est pas possible de la faire sur le disque système, le mieux est probablement de disposer d'un CD (ou clé USB) avec un système minimal et le très fameux WIPER.
Toutefois il n'est pas besion d'exécuer cette manip tous les jours ! Sur un disque très chargé en écriture comme le mien (cela s'est calmé depuis) il a fallu plusieurs mois avant de ressentir le ralentissement en écriture, la lecture restait OK.
J'ai refait les tests "iozone" (il faut conserver les scripts !) lors desquels j'avais trouvé des performances "horribles" en écriture sur une machine et les résultats sont là : il faut trimer pour que le disque bosse à la vitesse max.
Note : cette machine avait servi à de nombreuses compilations (et installations) de noyaux et de différentes version de XEN, opérations qui réalisent énormément d'écritures.
Voici deux séries d'image dans le style AVANT/APRES bien connu des publicitaires .... mais ce n'est pas du rêve, c'est bien la réalité
| Avant | Après |
"Write"  |
 |
Random Write  |
 |
Record Write  |
 |
C'est assez spectaculaire, et c'est bien, physiquement, le même disque ... vive le TRIM.
Une séance de trim :
1) Test sans valider, "pour voir"
# ./wiper.sh /dev/sdb2
wiper.sh: Linux SATA SSD TRIM utility, version 2.6, by Mark Lord.
Hdparm version
Target=/dev/sdb2 Method=offline
Preparing for offline TRIM of free space on /dev/sdb2 (ext3 non-mounted).
This will be a DRY-RUN only. Use --commit to do it for real.
Syncing disks..
Simulating TRIM operations..
(dry-run) trimming 37690664 sectors from 8058 ranges
Done.
2) Un passage "en vrai" :
./wiper.sh /dev/sdb2 --commit
wiper.sh: Linux SATA SSD TRIM utility, version 2.6, by Mark Lord.
Hdparm version
Target=/dev/sdb2 Method=offline
Preparing for offline TRIM of free space on /dev/sdb2 (ext3 non-mounted).
This operation could silently destroy your data. Are you sure (y/N)? y
Syncing disks..
Beginning TRIM operations..
/dev/sdb:
trimming 37690664 sectors from 8058 ranges
succeeded
Done.
Et en plus c'est très rapide, moins d'une minute. Le seul problème est que cela ne fonctionne pas sur un disque monté et un disque système non monté c'est légèrement gênant !
Mais si l'on a un autre disque bootable il n'y a aucun problème, on peut aussi démarrer sur un Live CD sur lequel on a installé le logiciel adéquat. J'ai deux disques bootables sur deux versions différentes du système dont une "stable", donc pas de problème de ce coté.
Le support du "TRIM" est partiel depuis le noyau 2.6.32 et limité aux filesystems "btrfs" (2.6.32) et "ext4" (2.6.33) en utilisant l'option "discard" dans la déclaration du périphérique dans "fstab", exemple :
/dev/sda1 / ext4 defaults,noatime,discard 0 0
Il va falloir passer le disque système en ext4, est-ce déjà judicieux ?