Réponse courte

• Choisissez ext4, et utilisez FITRIM (voir ci-dessous). Utilisez également l'option noatime si vous craignez "l'usure des SSD".

• Ne changez pas votre ordonnanceur I/O par défaut (CFQ) sur des serveurs multi-applications, car il assure l'équité entre les processus et prend en charge automatiquement les SSD. Cependant, utilisez Deadline sur les ordinateurs de bureau pour obtenir une meilleure réactivité sous charge.

• Pour garantir facilement un bon alignement des données, le secteur de départ de chaque partition doit être un multiple de 2048 (= 1 Mio). Vous pouvez utiliser fdisk -cu /dev/sdX pour les créer. Sur les distributions récentes, cela le fera automatiquement pour vous.

• Réfléchissez à deux fois avant d'utiliser le swap sur un SSD. Cela sera probablement beaucoup plus rapide par rapport au swap sur un HDD, mais cela usure également plus rapidement le disque (ce qui peut ne pas être pertinent, voir ci-dessous).

Réponse détaillée

• Systèmes de fichiers :

Ext4 est le système de fichiers Linux le plus courant (bien maintenu). Il offre de bonnes performances avec les SSD et prend en charge la fonction TRIM (et FITRIM) pour maintenir de bonnes performances des SSD dans le temps (cela efface les blocs mémoire inutilisés pour un accès en écriture rapide ultérieur). NILFS est spécialement conçu pour les lecteurs de mémoire flash, mais ne performe pas vraiment mieux qu'ext4 sur les benchmarks. Btrfs est encore considéré comme expérimental (et ne performe pas vraiment mieux non plus).

• Performances des SSD & TRIM :

La fonction [TRIM](https://en.wikipedia.org/wiki/Trim(computing))_ efface les blocs SSD qui ne sont plus utilisés par le système de fichiers. Cela optimise les performances d'écriture à long terme et est recommandé sur les SSD en raison de leur conception. Cela signifie que le système de fichiers doit pouvoir informer le disque de ces blocs. L'option de montage discard de ext4 enverra de tels commandes TRIM lorsque des blocs de système de fichiers seront libérés. Il s'agit d'un effacement en ligne.

Cependant, ce comportement implique un léger surcoût de performance. Depuis Linux 2.6.37, vous pouvez éviter d'utiliser discard et choisir plutôt de faire un effacement groupé occasionnel avec FITRIM à la place (par exemple, depuis la crontab). L'utilitaire fstrim le fait (en ligne), tout comme l'option -E discard de fsck.ext4. Vous aurez besoin de versions "récentes" (au moment de l'écriture) de ces outils cependant.

• Usure des SSD :

Vous voudrez peut-être limiter les écritures sur votre disque car les SSD ont une durée de vie limitée à cet égard. Ne vous inquiétez cependant pas trop, le pire SSD de 128 Go d'aujourd'hui peut supporter au moins 20 Go de données écrites par jour pendant plus de 5 ans (1000 cycles d'écriture par cellule). Les meilleurs (et aussi les plus gros) peuvent durer beaucoup plus longtemps : vous l'aurez très probablement remplacé d'ici là.

Si vous souhaitez utiliser du swap sur un SSD, le noyau détectera un disque non rotatif et réalisera une utilisation de swap aléatoire (nivellement d'usure au niveau du noyau) : vous verrez alors un SS (Solid State) dans le message du noyau lorsque le swap est activé :

Ajout de 2097148k de swap sur /dev/sda1. Priorité :-1 étendues :1 across: 2097148k SS

• Ordonnanceurs I/O :

Aussi, je suis d'accord avec la plupart de la réponse d'aliasgar (même si la plupart a été -illégalement ?- copié de ce site web), mais je dois partiellement désapprouver la partie sur l'ordonnanceur. Par défaut, l'ordonnanceur Deadline est optimisé pour les disques rotatifs car il met en œuvre l'algorithme d'ascenseur. Donc, clarifions cette partie.

Réponse détaillée sur les ordonnanceurs

À partir du noyau 2.6.29, les disques SSD sont détectés automatiquement, et vous pouvez vérifier cela avec :

cat /sys/block/sda/queue/rotational

Vous devriez obtenir 1 pour les disques durs et 0 pour un SSD.

Maintenant, l'ordonnanceur CFQ peut adapter son comportement en fonction de cette information. Depuis Linux 3.1, le fichier de documentation du noyau cfq-iosched.txt dit :

CFQ possède quelques optimisations pour les SSD et s'il détecte un support de médias non rotatif qui peut gérer une profondeur de file d'attente plus élevée (multiples requêtes en cours en même temps), [...].

De plus, l'ordonnanceur Deadline tente de limiter les mouvements de tête désordonnés sur les disques rotatifs, en se basant sur le numéro de secteur. Citant la documentation du noyau deadline-iosched.txt, la description de l'option fifo_batch se trouve ici :

Les requêtes sont regroupées en "lots" d'une direction de données particulière (lire ou écrire) qui sont servis dans l'ordre croissant des secteurs.

Cependant, régler ce paramètre à 1 lors de l'utilisation d'un SSD peut être intéressant :

Ce paramètre ajuste l'équilibre entre la latence par requête et le débit agrégé. Lorsque la faible latence est la principale préoccupation, plus petit est meilleur (où une valeur de 1 donne un comportement du premier arrivé, premier servi). Augmenter le fifo_batch améliore généralement le débit, au détriment de la variation de la latence.

Certains benchmarks suggèrent que il y a peu de différence de performance entre les différents ordonnanceurs. Alors, pourquoi ne pas recommander la justesse ? quand CFQ est rarement mauvais sur le banc.

Cependant, sur les configurations de bureau, vous expérimenterez généralement une meilleure réactivité en utilisant Deadline sous charge, en raison de sa conception (probablement à un coût de débit inférieur cependant).

Cela dit, un meilleur benchmark consisterait à essayer Deadline avec fifo_batch=1.

Pour utiliser Deadline sur les SSD (et les disques NVMe & mémoire flash) par défaut, vous pouvez créer un fichier, disons /etc/udev.d/99-ssd.rules comme suit :

# tous les dispositifs de blocs non rotatifs utilisent l'ordonnanceur 'deadline'
# surtout utile pour les SSD sur des systèmes de bureau
SUBSYSTEM=="block", ATTR{queue/rotational}=="0", ACTION=="add|change", ENV{DEVTYPE}=="disk", ATTR{queue/scheduler}="deadline"