SSD : depuis que l'on en parle j'avais envie de tester ce genre de bête. 
J'ai craqué et cassé ma tire-lire pour pouvoir disposer d'un de ces trucs : "OCZ Vertex Turbo series" de 30Go avec un cache de 64Mo. 
Par ailleurs mon système XEN étant le résultat de nombreuses migrations :

• Suse SLES 10
• Suse SLES 10 SP1
• Suse SLES 10 SP2
• Suse SLES 11
• OpenSuse  11.1

Son disque système devait commencer à être assez bizarre, j'ai décidé de "repartir à zéro" et d'utiliser mon nouveau disque comme disque système. 
Tout ça c'était avant mon retour à Debian, pensez ma première machine Linux était une Debian avec un kernel 1.0.1 sur un Amiga 2000 dopé au 68060. 
J'ai sauvegardé sur un disque externe tout ce qui avait de la valeur (par exemple le répertoire "/etc" et d'autres bricoles). 
Je démonte les disques de stockage de données par sécurité (2 x 1To en miroir car toutes mes Machines virtuelles sont dessus), je les remettrai en service plus tard, on n'est jamais trop prudent ! Ne doutant de rien j'ai tenté d'installer une OpenSuse 11.2 en rc1 voir site  http://www.opensuse.org . Après quelques ennuis de gravure (ISO mal récupérée ?), c'est bizarre comme cela énerve, j'ai enfin réussi à créer le CD miracle. Malheur, lors de l'installation de cette 11.2 il y a un problème de génération du fichier "initrd" et des erreurs diverses qui rendaient le système inutilisable. Je suis repassé sur une OpenSuse 11.1 (stable) dont j'avais le DVD et ... l'installation a foiré sur mon beau SSD tout neuf ... 
Après quelque réflexion, j'ai lu des bricoles sur les problèmes d'installation de systèmes sur des SSD, j'ai décidé de frapper un grand coup : j'ai réduit (sniff) fortement la vitesse du CPU (multiplicateur passé de 11x à 7x), en bref j'ai transformé ma belle machine en brouette ... et celà a fonctionné ! L'installation de la 11.1 s'est fort bien passée. J'ai admiré au passage la beauté de l'installeur OpenSuse dont les graphismes sont parfaits, toutes les options de formatage des partitions sont assez bien foutues (si l'on met l'écran à 1024x768 au moins ...) et tout se passe bien. J'ai abandonné la partition spécifique "BOOT" et tout mis dans une seule partition du SSD. Après le paramétrage de l'installation tout est automatique et s'est déroulé en à peu près 30 minutes (malgré le 7x). Note : il vaut mieux "nommer" les partitions pour être dans la course, ma partition root se voit donc nommée "ROOT" (très original). Une seule partition sur l'ensemble du SSD (29,8 GO) nommée "ROOT" et montée par label. Après un arrêt pour remettre le multiplicateur à 11x le boot est super rapide, le chargement des logiciels presque instantané, OpenOffice apparaît très rapidement sur l'écran, en bref c'est super agréable. Vive le SSD ! Comme je disposais toujours de mon DVD 11.2 et que j'avais un peu de temps j'ai décidé de refaire une installation de 11.2 avec le multiplicateur réduit à 7x, on efface tout et on recommence. 
C'est parti :

• on redéfinit les partitions (idem à celle définies précedemment),
• on choisit les logiciels à installer (on utilise le bureau KDE car "gdm" ne fonctionne pas/mal avec le kernel XEN.
• on crée les utilisateurs "de base" en faisant attention à ne pas leur configurer un login automatique, c'est ennuyeux par la suite

"Suivant" l'installation démarre ... après environ 15 minutes la machine reboote pour la phase de configuraton. Aucune erreur ... bizarre le système gère mal l'installation sur SSD lorsque l'on est à pleine vitesse ???? La phase de configuration automatique se lance et ne signale aucun problème. 5 minutes après je dispose d'un beau bureau Gnome avec couleurs personnalisées par Suse,  avec un logo Suse stylisé en fond, très smart en vert olive et noir. Je vais voir un peu ce que cela donne après un reboot er remise en place du multiplicateur à 11X. Beagle est en train d'indexer je le laisse finir avant de rebooter. Une petite image de l'écran Gnome :

C'est beau ! 
On configure le réseau, tiens la configuration est construite directement avec des ponts, il n'y aura peut-être pas d'ennuis avec les machines virtuelles. 
Enfin on va rebooter et passer en vitesse normale, fini le ralenti. 
Après reboot le système répond très bien, c'est super... 
Essayons Xen maintenant, on reboote sur le noyau XEN et horreur l'écran graphique est tout bizarre, ce doit être une oeuvre abstraite. Mais, sans rigoler, l'accès est impossible en mode graphique et bloque le clavier si l'on a le malheur de cliquer. 
La machine reste toutefois accessible par ssh ... essayons de lancer une MV par ssh, "xm new MV" puis "xm start MV", tiens cela a l'air de marcher ... la machine virtuelle est accessible de l'extérieur, une petite connexion en X permet un accès graphique normal à la MV, tout est donc normal à part cet écran graphique bloqué ! 
Je tente alors de passer par kdm au lieu de gdm, plus de GNOME mais du KDE. 
En mode non-XEN tout est OK, le fonctionnement est parfait l'écran KDE est lui aussi très esthétique. 
En mode XEN ... ce n'est pas mieux qu'avec GNOME l'écran graphique reste dans un état "bizarre" et tant que l'on a pas cliqué sur cet écran de malheur on peut commuter sur les terminaux caractère par Ctrl+Alt+Fn. 
Vite un petit rapport de bug pour tenter d'aider à résoudre ce problème :

• Bug non encore répertorié (Release Candidate), tout est normal en 11.1, je l'ouvre
• Rapidement un début de solution : dire à XEN de n'utiliser que 4Go, ... et ça marche, la session X s'ouvre et on peut lancer une machine virtuelle en interactif.
• Une piste pour la solution de ce bug existe, une limite mémoire à 4Go cela me rappelle un système 32bits ! 'ai proposé de tester le patch dès qu'il sera disponible.
• 7 Novembre : le patch est disponible ... il concerne "vmalloc.c" qui semblait ne pas bien s'entendre avec Xen. Le patch passé on recompile le noyau sous un autre nom. Après ajout des lignes "qui vont bien" dans le fichier de configuration de grub (menu.lst) on teste et c'est OK ! 
  Toute la mémoire est reconnue sous Xen, le serveur X se lance correctement, tout est pour le mieux dans le (presque) meilleur des mondes. J'espère que ce patch va être intégré dans la version définitive.

Evidemment ce n'est pas terrible de limiter à 4Go, je le vois mal sur un serveur de production (j'en connais à 64 Go) avec 2 douzaines de MV). Enfin je peux tester cette version 11.2 avec un XEN 3.4.1 dernier cri. Et cela marche assez bien. 
Pour montrer que cela marche je ne résiste pas à montrer l'écran avec la MV sur laquelle je suis en train de travailler (KDE + Windows) : 
 

Cela prouve que tout marche ! 

En bref SSD c'est OK, à part lors de l'initialisation du système où quelque chose ne "suit" pas. 
Tests de vitesse :

• Sur un RAID (miroir) SATA : 
  hdparm -t /dev/md1 
  /dev/md1: 
  Timing buffered disk reads:  232 MB in  3.00 seconds =  77.25 MB/sec
• Sur le SSD : 
  hdparm -t /dev/sdc1 
  /dev/sdc1: 
  Timing buffered disk reads:  508 MB in  3.00 seconds = 169.26 MB/sec

Ces différences expliquent la réduction du temps de boot, le confort ressenti au chargement d'applications. 
Temps de boot du système depuis le choix du noyau (GRUB) < 16 secondes pour l'invite de X, le système contient  4 disques de données (miroir et LVM) en plus du SSD et deux interfaces réseau ce qui rallonge le temps de boot. 

En bref : SSD c'est presque OK ! Pour terminer, économisez votre SSD en lui évitant des ordres d'écriture dont il peut se passer, utiliser les options "nodiratime" et "relatime / noatime" dans le fichier /etc/fstab, voici la ligne correspondante dans mon propre fichier fstab : 
UUID=e5a02c97-cba2-4198-9b7a-1b1d354143ba  /  ext3  relatime,nodiratime,errors=remount-ro     0       1 
cela pourrait être aussi :  
/dev/sda1         /               ext3    relatime,nodiratime,errors=remount-ro     0       1

Les disques SSD sont très performants, c'est communément admis, mais qu'en est-il en réalité. Les systèmes Linux présentent plusieurs schedulers d'entrées/sorties, lequel est le plus adapté aux disques SSD ? 
Pour le savoir j'ai fait un certain nombre de mesures sur deux machines et avec plusieurs noyaux différents qui ont tous été compilés "à la maison". 
Le scheduler IO peut facilement être modifié dynamiquement disque par disque en intervenant dans le répertoire "/sys/block", dans ce répertoire on trouve un répertoire par disque physique contenant tout ce qu'il faut, entre autres un répertoire "queue" : 
ls -al /sys/block/sda/queue 
total 0 
drwxr-xr-x 3 root root    0 2010-01-27 15:00 . 
drwxr-xr-x 8 root root    0 2010-01-27 14:59 .. 
-r--r--r-- 1 root root 4096 2010-01-27 15:00 hw_sector_size 
drwxr-xr-x 2 root root    0 2010-01-27 15:10 iosched 
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 iostats 
-r--r--r-- 1 root root 4096 2010-01-27 15:10 logical_block_size 
-r--r--r-- 1 root root 4096 2010-01-27 15:10 max_hw_sectors_kb 
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 max_sectors_kb 
-r--r--r-- 1 root root 4096 2010-01-27 15:10 minimum_io_size 
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 nomerges 
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 nr_requests 
-r--r--r-- 1 root root 4096 2010-01-27 15:10 optimal_io_size 
-r--r--r-- 1 root root 4096 2010-01-27 15:10 physical_block_size 
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 read_ahead_kb 
-rw-r--r-- 1 root root 4096 2010-01-27 15:00 rotational 
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 rq_affinity 
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 scheduler 

Le fichier "scheduler" contient la liste des schedulers (elevator) disponibles dans votre noyau : 
cat scheduler 
[noop] anticipatory cfq deadline 
Le scheduler actif est entouré de "[ ]" (brackets dans le texte). 
Note : "anticipatory" a disparu dans le noyau 2.6.33. 
Je vais tenter d'autres test plus représentatifs le la vie réelle (???) pour mieux mesurer l'influence (éventuelle ? ) du scheduler d'IO.Les tests réalisés sur plusieurs noyaux sont extrêmement longs et obligent à des "reboot" fréquents. 
Commentaires sur les résultats.

• La dépendance des résultats au noyau est très forte (rappel : les noyaux sont compilés avec les mêmes options)
• Dans les tests "vraie vie" la différence SSD/SATA est soit invisible soit pas dans le sens prévu (tests GZIP)
• La dépendance par apport au scheduler d'IO est extrêmement faible et ne dépasse pas quelques pourcents.
• En lecture pure (test hdparm) les SSD sont nettement plus performants (jusqu'au noyau 2.6.32 ?)

Quelques tests réalisés sur le noyau 2.6.32 on donné des résultats catastrophiques pour le SSD, 20% moins bien que le disque classique aux tests hdparm. 
J'ai récupéré et compilé un 2.6.33 (rc5) pour compléter les tableaux. Au niveau du test "hdparm" le résultat est très dégradé pour le SSD, par contre au niveau du test de compilation de 2.6.33 a fait des miracles. 
Les mesures obtenues avec "hdparm" étant un peu "bizarres" avec les disques SSD à partir du noyau 2.6.32 je pense qu'une modification importante des schedulers IO est en cours, c'est confirmé par la disparition du scheduler "anticipatory" dans le 2.6.33. Ces modifications rendent les résultats de "hdparm" tellement bizarres (anormaux et irréguliers pour les SSD) que ces résultats sont à prendre avec des pincettes. 
Dernières nouvelles les tests "hdparm" sont en cours de réfection avec un paramètre supplémentaire permettant un accès plus "direct" au hardware ( option --direct). Une nouvelle page est en préparation. 
 

Le nouveau/futur système de fichiers pour Linux semble être BTRFS car celui-ci est censé apporter un certain nombre de nouveautés et de facilités que d'autres systèmes (Solaris 10?) possèdent et qui simplifient la vie des administrateurs.

La possibilité d'agrandir, de réduire des FS, de jouer avec les modes RAID et d'effectuer des "snapshots" de manière simple et au sein du même outil devrait apporter beaucoup plus de souplesse au niveau de l'administration.

Mais BTRFS n'est pas encore prêt pour passer en production et les outils en version 0.19 rappellent bien que ce système est encore en période de rodage ! 
Note 2016 : BTRFS est maintenant "adulte" et suffisamment stable pour la production.

Je vous propose toutefois quelques tests "pour voir".

Note : le système est un Debian "Jessie" mais la plupart des remarques peuvent s'appliquer à d'autres distributions. 
Sur la machine qui me sert de frontal Internet j'ai eu de multiples alertes "Smart" me signalant des dégradations sur des "seek..." et quelques autres anomalies. Ces disques sont assez anciens et très sollicités car la machine fonctionne 24/24 et héberge plusieurs services : mail, DNS, DHCP, serveur Apache, agent centralisateur de collectd, une base Mysql ainsi que Suricata et Snorby. Les deux disques de cette machine (500Go) deviennent par ailleurs un peu petits. Ils sont montés en LVM, chaque volume LVM est mirroré, mais c'est un peu lourd à gérer. Le système est sur un petit SSD que je sauvegarde régulièrement. 
J'ai donc décidé de changer les disques et de mettre deux disques en RAID1 sur lesquels je mettrais trois partitions, dont deux avec LVM, plus un swap. Il ne faut pas oublier de charger le paquet "mdadm" pour disposer des outils adéquats.  
Comme le contrôleur supporte 4 disques j'ai pu monter un des futurs disques en plus afin de : 
- Le partitionner :

1. une partition pour le système,
2. une pour les disques des machines virtuelles,
3. une pour le stockage des données
4. une de swap.

Ensuite :

• Créer le Raid1 avec une seule patte.
• Créer les PV pour LVM sur les partitions 2 et 3
• Charger les données, du système et copier les images de machines virtuelles.

Pour ceci il est nécessaire de stopper le maximum de services afin de ne pas se compliquer la tâche. 
Ne pas oublier de mettre les partitions en type "Linux RAID" dans fdisk (type "fd") : 
Command (m for help): t 
Partition number (1-4, default 4): 1 
Partition type (type L to list all types): 21 
Changed type of partition 'Linux RAID' to 'Linux RAID'. 
... idem pour les autres partitions. 
On arrive alors à ceci dans fdisk :

Disk /dev/sdc: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 4096 bytes 
I/O size (minimum/optimal): 4096 bytes / 4096 bytes 
Disklabel type: gpt 
Disk identifier: 48D952DA-AF21-46D3-BB36-73DFFF32A96A 
Device          Start        End   Sectors  Size Type 
/dev/sdd1        2048  536872959 536870912  256G Linux RAID 
/dev/sdd2   536872960 1073743871 536870912  256G Linux RAID 
/dev/sdd3  1073743872 1912604671 838860800  400G Linux RAID 
/dev/sdd4  1912604672 1953525134  40920463 19,5G Linux RAID

Ensuite il faut créer nos "RAID" en mettant à chacun un disque physique et un disque "missing" : 
mdadm --create /dev/md2 --level=1 --raid-disks=2 missing /dev/sdd1 
.... 
Puis enregistrer la config de nos RAID pour qu'ils soient reconnus au boot avec : 
mdadm --examine --scan >>/etc/mdadm/mdadm.conf 
Vous pouvez ensuite modifier dans ce fichier l'adresse mail de destination des messages. 
Il est prudent de redémarrer la machine pour vérifier que nos RAID sont bien accrochés et se retrouvent après redémarrage.

On arrive alors a "voir" l'état de nos RAID en exécutant :  
cat /proc/mdstat 
Personalities : [raid1]  
md3 : active raid1 sdc2[1] 
      268304384 blocks super 1.2 [2/1] [_U] 
      bitmap: 1/2 pages [4KB], 65536KB chunk

md4 : active raid1 sdc3[1] 
      419299328 blocks super 1.2 [2/1] [_U] 
      bitmap: 1/4 pages [4KB], 65536KB chunk

md5 : active raid1 sdc4[1] 
      20443840 blocks super 1.2 [2/1] [_U] 
       
md2 : active raid1 sdc1[1] 
      268304384 blocks super 1.2 [2/1] [_U] 
      bitmap: 2/2 pages [8KB], 65536KB chunk

unused devices: <none> 
------------------------------------------------------- 
Le système signale par ailleurs dans les logs lors du démarrage que les RAID ne sont pas en bon état : 
Nov 25 13:24:49 xxxxxx systemd-fsck[408]: /dev/md2 : propre, 17129/16769024 fichiers, 10491322/67076096 blocs 
Nov 25 13:24:49 xxxxxx systemd-fsck[516]: BOOT : propre, 326/1222992 fichiers, 139566/4882432 blocs 
Nov 25 13:24:49 xxxxxx mdadm-raid[196]: Assembling MD array md2...done (degraded [1/2]).

et mdadm-raid vous envoie régulièrement des mails tels que : 
This is an automatically generated mail message from mdadm 
running on xxxxxx.xxx.xxx

A DegradedArray event had been detected on md device /dev/md/4.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid1] 
md4 : active raid1 sdc3[1] 
      419299328 blocks super 1.2 [2/1] [_U] 
      bitmap: 1/4 pages [4KB], 65536KB chunk

md5 : active raid1 sdc4[1] 
      20443840 blocks super 1.2 [2/1] [_U] 
....... 
------------------------------------------------------- 
On peut alors : 
Formater la première partition en ext4 
Recopier les répertoires système du vieux disque, /var, quelques morceaux de /usr ... sur la première partition, "cp -dpRx" est votre ami. 
Créer le PV LVM sur la deuxième partition puis créer les volumes logiques destinés à mes machines virtuelles (je ne le fais pas à la main mais avec "kvpm" que j'aime bien). 
Stopper les machines virtuelles et copier leurs images disque, bêtement avec : 
"dd if=ancien of=nouveau bs=65536" et cela marche très bien. 
J'ai ensuite modifié le fichier /etc/fstab" pour monter les "nouvelles" partitions à la place des "anciennes", les anciennes sont toujours là (au cas ou ?). 
Modifié les scripts de lancement des MV pour utiliser les nouveaux volumes et redémarré. 
Super, tout se passe bien, le système est OK, les MV ont bien démarré et leurs services sont accessibles. Je vais pouvoir démonter les anciens disques.  
Je stoppe encore la machine, démonte les anciens disques et je les stocke dans un coin tranquille (encore au cas ou) et monte le nouveau disque encore vierge.  
Il fait alors recommencer le partitionnement de ce nouveau disque, sans oublier de mettre le type de partition à "Linux RAID". 
Faire gaffe au nom des disques, car le démontage des anciens disques décale tout. On arrive presque à la fin on va, enfin, créer un vrai RAID1 avec deux disques : 
mdadm --manage /dev/md2 --add /dev/sdb1

cat /proc/mdstat 
Personalities : [raid1]  
md3 : active raid1 sdc2[1] 
      268304384 blocks super 1.2 [2/1] [_U] 
      bitmap: 1/2 pages [4KB], 65536KB chunk

md4 : active raid1 sdc3[1] 
      419299328 blocks super 1.2 [2/1] [_U] 
      bitmap: 1/4 pages [4KB], 65536KB chunk

md5 : active raid1 sdc4[1] 
      20443840 blocks super 1.2 [2/1] [_U] 
       
md2 : active raid1 sdb1[2] sdc1[1] 
      268304384 blocks super 1.2 [2/1] [_U] 
      [>....................]  recovery =  0.2% (781056/268304384) finish=28.5min speed=156211K/sec 
      bitmap: 2/2 pages [8KB], 65536KB chunk

La synchronisation de la première partie du RAID /dev/md2 est commencée et prévue pour un peu moins de 30 minutes, ne pas être pressé et éviter le café car il y a d'autres RAID à compléter. 
La vitesse de construction varie un peu mais reste supérieure à 100000K/sec mais la première partition fait 256G, la plus grosse 400G ce qui va durer une éternité. 
La première partition contient beaucoup de fichiers "actifs", par exemple tous les logs, la base de données mysql .... cela devrait augmenter le temps de construction. Mais, un peu plus tard : : 
md2 : active raid1 sdb1[2] sdc1[1] 
      268304384 blocks super 1.2 [2/1] [_U] 
      [================>....]  recovery = 84.4% (226534144/268304384) finish=6.7min speed=103609K/sec 
      bitmap: 2/2 pages [8KB], 65536KB chunk 
Ca s'approche de la fin .... toujours à un peu plus de 100MO/seconde. Au passage "iotop" ne voit rien et affiche des chiffres "ridicules". 
Nov 25 19:16:52 xxxxxx kernel: [  939.531841] md: recovery of RAID array md2 
Nov 25 19:59:28 xxxxxx kernel: [ 3493.885198] md: md2: recovery done. 
43 minutes environ au lieu des #30 annoncées. 
  
Pour la partition suivante il y a deux disques de machines virtuelles, je ne vais pas les stopper avant de commencer la construction du RAID pour environ 30 minutes annoncées. 
Nov 25 20:34:04 xxxxxx kernel: [ 5569.372170] md: recovery of RAID array md3 
Nov 25 21:24:56 xxxxxx kernel: [ 8618.957262] md: md3: recovery done. 
Soit environ 50 minutes. 
J'aurais mieux fait de stopper les MV car l'une d'elle a eu un problème lors du redémarrage (fsck manuel obligatoire).

Passons à la partition de 400G. 
mdadm --manage /dev/md4 --add /dev/sdb3 
mdadm: added /dev/sdb3 
date 
mercredi 25 novembre 2015, 21:28:55 (UTC+0100) 
Et quelques instants plus tard : 
cat /proc/mdstat 
Personalities : [raid1]  
md4 : active raid1 sdb3[2] sdc3[1] 
      419299328 blocks super 1.2 [2/1] [_U] 
      [=>...................]  recovery =  6.5% (27293696/419299328) finish=95.4min speed=68420K/sec 
      bitmap: 0/4 pages [0KB], 65536KB chunk 
La vitesse n'est "que" de 68Mo/seconde ? On doit approcher le milieu du disque ??? 
Beaucoup plus tard ... : 
cat /proc/mdstat 
Personalities : [raid1]  
md4 : active raid1 sdb3[2] sdc3[1] 
      419299328 blocks super 1.2 [2/1] [_U] 
      [=======>.............]  recovery = 36.8% (154667968/419299328) finish=70.2min speed=62746K/sec 
      bitmap: 0/4 pages [0KB], 65536KB chunk 
date 
mercredi 25 novembre 2015, 22:05:02 (UTC+0100) 
En 37 minutes le temps restant n'a que diminué de 25 minutes .... que dire du résidu de 70 minutes ? Ensuite en 20 minutes le temps restant a diminué de 15 minutes. 
A 22:40 ( durée 72 minutes) il reste encore 36 minutes .... 
cat /proc/mdstat ; date 
Personalities : [raid1]  
md4 : active raid1 sdb3[2] sdc3[1] 
      419299328 blocks super 1.2 [2/1] [_U] 
      [=================>...]  recovery = 89.9% (377065408/419299328) finish=13.5min speed=52082K/sec 
      bitmap: 0/4 pages [0KB], 65536KB chunk 
mercredi 25 novembre 2015, 23:09:29 (UTC+0100) 
Les 100 minutes sont atteintes il n'en reste plus que 13,5 mais la vitesse est tombée à 52MO/seconde. Pour finir : 
Nov 25 21:28:53 xxxxxx kernel: [ 8856.327974] md: recovery of RAID array md4 
Nov 25 23:24:41 xxxxxx kernel: [15800.532184] md: md4: recovery done. 
1h56 minutes soit 116 minutes, heureusement que je n'ai pas utilisé des disques de 3To !

La dernière partition (futur SWAP) ne fait que 19G, cela devrait aller vite : 
md5 : active raid1 sdb4[2] sdc4[1] 
      20443840 blocks super 1.2 [2/1] [_U] 
      [>....................]  recovery =  1.5% (311040/20443840) finish=9.7min speed=34560K/sec 
Par contre même pas 35MO/seconde ! Cette partie du disque est vraiment moins performante, mais après quelques minutes on monte à environ 45Mo/seconde ce qui est déjà un peu mieux. 
Enfin, c'est fini !  
La machine est sauvée et n'aura peut-être pas d'incident disques avant quelques années ... je croise les doigts. 
 

Ayant eu l'occasion de me procurer deux SSD de 512Go j'ai rapidement décidé de les utiliser pour fournir l'espace disque à quelques machines virtuelles. 

Installation précédente : 
- Deux disques Hitachi Deskstar de 3To montés en miroir (DMRAID) avec deux Volume Group LVM.

Nouvelle installation : 
- Deux disques Samsung SSD 850 PRO 512GB montés en miroir (DMRAID) avec deux VG LVM.

Les deux nouveaux disques sont utilisés comme support d'un Volume Group LVM dans lequel j'ai pu "tailler" l'espace nécessaire à quelques machine virtuelles et d'un autre dédié à une base Mysql de quelques Go utilisées sur le système hôte et il y reste encore un peu de place. 
 La différence est très sensible sur les temps de réponse de la base Mysql : de gros "select count(*) from ..." sont passés de plus d'environ deux minutes à une trentaine de secondes, soit approximativement une performance quatre fois meilleure, comme mesuré dans l'article indiqué ci-dessous. 
 Pour les machines virtuelles la différence est également importante, le serveur Web, sur lequel sont installées ces pages assure un temps de réponse bien meilleur et les statistiques apparaissent bien plus rapidement, décidément Mysql aime les SSD et le montre bien. (Voir article Mysql et SSD). Quand à l'interface d'administration de Drupal il est devenu agréable à utiliser, pratiquement plus d'attente entre les pages. 
Une des MV est un serveur de mail Zimbra dont l'interface d'administration fournit des statistiques diverses dont une sur l'usage CPU. Une des statistiques m'a particulièrement intéressé, celle des IOWait qui est très significative.  

On voit bien la baisse des Cpu_iowait lors du redémarrage de la machine. 

Le ressenti de l'interface Webmail est meilleur la réponse plus franche et plus rapide. 
En bref : les SSD c'est le pied.

Un petit graphe des IO pour les deux machines : 
SSD

Encore un test SSD/HDD ? J'ai récemment installé une base volumineuse sur une machine munie de SSD et j'ai constaté que les temps de réponse étaient excellents. Afin de quantifier le phénomène j'ai installé la même base sur deux machines différentes (#90 millions de rangs dans la table principale) :

Machine 1 : 
Core I7 6700 à 3.4 Mhz 
RAM : 16Go 
Base sur une partition dédiée d'un ensemble Raid1 sur HDD classique. 
Mysql 5.7.22 Inno_buffers en mémoire classique 
Machine 2 : 
Core I5 7500 à 3.4 Mhz 
Raml : 16Go 
Mysql 5.7.22 Inno_buffers en mémoire "huge pages" 
Base sur une partition dédiée d'un ensemble Raid1 sur SSD. 
Les deux machines sont donc à peu près équivalentes en vitesse au point de vue des CPU puisque Mysql n'utilise qu'un CPU par requête et que le paramétrage de Mysql est identique sur les deux systèmes. Seule différence la machine 2 utilise des "huge pages" pour les buffers InnoDB.

Le premier test consiste à :

• Récupérer dans une table temporaire des rangs présents sur une autre machine par l'intermédiaire d'une table "federated".
• Insérer ces rangs dans une table permanente.

Test 1. 
Machine 1 : 
Récupérer 206020 rangs      11.48 sec 
Insérer dans table "réelle"    69.70 sec 
Machine 2 : 
Récupérer 212290 rangs       5,42 sec 
Insérer dans table "réelle"    11,92 sec

Test 2. 
Machine 1 : 
Récupérer 2495 rangs           4,76 sec 
Insérer dans table "réelle"     1,87 sec 
Machine 2 : 
Récupérer 2482 rangs           0,32 sec 
Insérer dans table "réelle"     0,12 sec

Test 3. 
Machine 1 : 
Récupérer 2495 rangs           9,66 sec 
Insérer dans table "réelle"     57,04 sec 
Machine 2 : 
Récupérer 2482 rangs           2,22 sec 
Insérer dans table "réelle"     7.85 sec

Après quelques autres tests le tableau récapitulatif : 

Au final la base sur SSD effectue les opérations presque 5,7 fois plus rapidement.

Tableau à partir des mêmes données mais en rangs traités par seconde : 
 
Pour l'insertion le SSD semble moins "bon" mais cette phase comprends la lecture sur la machine origine et le transfert par le réseau qui sont probablement égaux pour les deux machines. 

Deuxième test : compter les rangs de la plus grosse table. 
Pour ce test :

1. On redémarre Mysql pour bien vider les caches
2. On exécute deux comptages successifs (# 90 millions de rangs).

Machine 1 : 
Premier comptage : 48,36 sec 
Comptage suivant : 22,65 sec 
Machine 2 : 
Premier comptage : 22,07 sec 
Comptage suivant : 19,44 sec

Même test le lendemain après ajout de #133000 rangs pour un total de 91176892 
Machine 1 : 
Premier comptage : 52,24 sec 
Comptage suivant : 22,61 sec 
Machine 2 : 
Premier comptage : 21,91 sec 
Comptage suivant : 19,59 sec

La différence est moins importante mais le SSD gagne quand même par plus de 2 à 1 sur le comptage "brut". On constate quand même la bonne efficacité des caches. 
iotop montre de la lecture a #30 Mo/sec pour les HDD et > 60Mo/sec pour les SSD. 
Le deuxième comptage est visiblement effectué sur les caches (peu ou pas d'IO visibles), la différence d'environ 10% est très probablement due à l'usage des "huge pages" pour le cache InnoDB de la machine 2 (large-pages pour Mysql). 
Un petit graphe des IO pour les deux machines : 
 
 
Petite bizarrerie au démarrage pour le SSD qui met #7 secondes pour arriver à son plein régime ? 
La même remarque s'applique à plusieurs tests. 
On peut voir par ailleurs que les temps de comptage sur la machine SSD sont très peu différents entre le premier comptage (avec accès disque) et le suivant réalisé immédiatement (ne montrant pas d'IO), les disques SSD ne semblent quasiment pas ralentir le traitement (#10% de différence seulement) par rapport au traitement depuis le cache.

Troisième test : créer un nouvel index. 
L'index est composé de trois champs. 
Machine 1 : 23 min 42,63 sec 
Machine 2 :  5 min 29,11 sec 
Le rapport de durée est d'environ 4,3. 
Pendant l'exécution j'ai vu plus de 240Mo/seconde en lecture sur les SSD contre un peu plus de 60Mo/seconde pour les HDD.

Afin de mesurer un peu l'influence des disques sur une base Mysql j'ai effectué quelques petits tests par rapport à une base de référence installée sur des disques « classiques » 7200 tours. 
Les test réalisés :

1.  Sur la machine d'origine (Core I5 à 3.4GHz, disques « classiques »), Mysql 5.6.30
2.  Sur une autre machine (Corei3 à 3.5GHz, tout SSD) le test est réalisé avec une installation « standard » de Mysql (5.6.30). Donc tout sur le disque système (/var/lib/mysql et /var/log/mysql)
3.  Toujours sur la machine SSD (5.6.30) avec une installation un peu plus optimisée :
   •      Logiciel sur le SSD système
   •      Données sur un SSD « DATA »    (/var/lib/mysql)
   •      Logs sur un autre SSD « LOG »   (/var/log/mysql + tmpdir)
4. Le dernier test est réalisé sur la configuration « optimisée » avec la version 5.7.16

La base n'est pas énorme et comporte deux tables principales de # 10 millions et #100000 rangs et "tient" dans # 4Go.

Les résultats sont assez parlants, le passage sur SSD apporte une très nette amélioration de performance et pourtant le SSD supportant le système est un "vieux" modèle qui n'est pas au niveau des derniers modèles. 
Voir un autre test sur le même sujet.

Et en image cela donne :

Dernier test : comptage sur une "grosse" table :

Machine SSD : 
+-----------+ 
| count(*)  | 
+-----------+ 
| 134071332 | 
+-----------+ 
1 row in set (50,52 sec)

Machine HDD : 
+-----------+ 
| count(*)  | 
+-----------+ 
| 134072138 | 
+-----------+ 
1 row in set (4 min 9,46 sec)

Environ 5/1 en faveur du SSD.