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. 
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 pres 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 apparait 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 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