On trouve certaines offres d’accélération de disque dur par SSD (Solid‐State Drive, disque électronique Flash) destinées aux systèmes d’exploitation propriétaires, et ZFS intègre aussi une solution L2ARC performante et éprouvée depuis un bon moment pour le stockage sous Solaris. Or, du côté de Linux, une solution standard n’existe pas encore.
J’en profite donc pour mettre en forme l’ensemble des informations récoltées depuis un moment.
NdM : Merci à fcartegnie pour son journal.
Stratégies de cache
Le write‐around, ou cache en lecture uniquement
Les blocs modifiés sont écrits directement sur le disque dur, et à cette occasion l’entrée en cache du SSD est invalidée. Il n’est donc bénéfique que si le nombre de lectures d’un bloc est supérieur à 1 avant sa modification. En supposant que les accès sont suffisamment diversifiés pour qu’ils ne se trouvent pas dans le cache de Linux lui‐même.
Le write‐through, ou cache complet
Les blocs modifiés sont écrits simultanément sur le SSD et le disque dur. L’entrée modifiée se trouve donc immédiatement disponible dans le cache SSD, jusqu’à son éviction.
Le write‐back, ou cache complet avec tampon et file d’écriture
Similaire au write‐through, mais les écritures ne sont pas instantanées et peuvent être réorganisées (similaire au NCQ pour le SATA ou TCQ en SCSI).
Ce type d’opération est généralement fait dans les micro‐logiciels (firmwares) récents (notamment pour éviter d’écrire plusieurs fois une cellule dont les blocs sont écrits successivement).
Particularités et problèmes
La commande TRIM
Les problématiques de libération de blocs et de dégradation de performances sont résolues par la commande TRIM sur les SSD directement connectés. Mais il faut donc aussi que cette dernière soit gérée par le cache.
TRIM over mapper or RAID
Même problème pour la carte des périphériques (device mapper) et donc le RAID. Linux ne gère le TRIM en RAID que pour les modes 0 et 1.
L’amplification en écriture
Un des effets connus des disques ne supportant par le TRIM. Voir Wikipédia.
La création de goulets d’étranglement
Voir discussion sur bcache.
Les modules de cache
bcache
Linux kernel block layer cache est un candidat sérieux pour être intégré au noyau. Il fournit toutes les stratégies write‐through et write‐back. Un patch a aussi été proposé pour l’insérer directement dans l’architecture dm.
bcache permet d’utiliser un SSD comme cache pour un grand nombre de disques. Ce faisant, un goulot d’étranglement est créé et, dans certaines conditions, atteindre les limites du SSD va entraîner une dégradation des performances. bcache propose donc un algorithme permettant d’estimer les limites du SSD et le cas échéant de court‐circuiter le cache.
On se posera tout de même la question de la réalité de ce problème dans le monde réel, sachant qu’un disque traditionnel fournit au mieux 200 entrées‐sorties par seconde et un ancien SSD SLC en fournit 5 000 : ça fait une configuration d’un SSD pour 25 disques durs accélérés…
Les moins :
- nécessite de formater spécialement les disques cibles (pour une raison d’exclusivité d’accès, afin d’éviter la corruption des données).
flashcache
La solution développée par Facebook qui fournit toutes les stratégies de cache.
Les moins :
- ne gère pas le TRIM pour l’instant ;
- mise en place plus complexe que bcache.
dm_mod
La carte des périphériques (mapper) du noyau, pas vraiment prévue pour jouer le rôle d’un cache de périphérique bloc, est utilisable d’une manière détournée. L’option « write‐mostly » destinée à donner une priorité à un membre d’une réplication dm RAID a pour but de permettre un cache local pour le stockage réseau. (ex : cible iSCSI répliquée sur une partition).
Répliquer un disque sur (marqué en write‐mostly) un SSD permet au final l’accélération de ce premier pour les lectures. On obtient un cache de type write‐around de ce fait.
Les moins :
- nécessite un volume SSD de taille identique ;
- dans le cas ou le disque SSD entier est utilisé, va allouer l’ensemble des blocs du SSD et générer une amplification en lecture (aucun bloc libre pour optimisation) ;
- ne supporte le TRIM qu’à partir de son introduction dans dm, soit 2.6.37
Le mot de la fin
Pour ceux qui préfèrent un résumé sous forme de tableau, voici le même article en anglais.
Aller plus loin
- Journal à l’origine de la dépêche (654 clics)
# Autre réglage possible...
Posté par FantastIX . Évalué à 3.
J'ai vu ou lu quelque part (peut-être dans un Linux Magazine) qu'il y avait aussi un réglage pour un composant appelé “ascenseur” (elevator?) dans le cadenceur d'entrées/sorties (IO scheduler). Dans le cas des SSD, on peut le régler sur "noop" pour éviter tout l'algorithme d'ordonancement. Je ne connais pas l'impact chiffré de ses effets par contre.
[^] # Re: Autre réglage possible...
Posté par Alexandre Belloni (site web personnel) . Évalué à 5.
C'est le scheduler d'I/O. Il est possible d'en choisir un différent pour chaque périphérique bloc. Le but est de réordonner les accès disques pour que les accès sur des sections physiquement proches se fassent en même temps, par exemple pour éviter de devoir bouger la tête d'un disque dur entre chaque écriture. Il est effectivement possible d'utiliser noop car dans le cas des SSD, le temps d'accès a un bloc ne dépend pas de la position du bloc précédent.
Voir /sys/block/*/queue/scheduler et http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/block/switching-sched.txt;hb=HEAD
[^] # Re: Autre réglage possible...
Posté par MTux . Évalué à 3.
D'ailleurs pour ceux qui utilisent Fedora, il y a une petite page de wiki qui y est dédiée :
doc.fedora-fr.org/wiki/Les_SSD_sous_fedora
La modification du IO scheduler y est décrite (passage en noop)
Je l'ai faite mais je considère que ces bidouilles (noatime…) tiennent plus du ramassage de miettes que du gain réel.
Du moins en usage desktop ça ne se voit pas.
Par contre activer TRIM semble important.
[^] # Re: Autre réglage possible...
Posté par antistress (site web personnel) . Évalué à 3.
C'est exactement le contraire, modifier l'ordonnanceur de tâches d'E/S n'apporte rien alors que spécifier l'attribut noatime fait une grande différence. Voir les liens donnés dans mon billet sur le sujet.
[^] # Re: Autre réglage possible...
Posté par MTux . Évalué à 3.
Il me semble que le noatime c'est pour éviter que le FS écrive des choses dans un fichier à chaque fois qu'il le consulte. Je ne vois pas pourquoi cela ferait une différence au niveau des performances surtout que les SSD sont meilleurs en temps d'accès que les disques durs. D'après moi l'intérêt est plutôt d'éviter les écritures inutiles et allonger la durée de vie. Mais là aussi j'estime que c'est du ramasse miettes. Que mon SSD tienne 20 ou 21 ans, de toutes façons il sera remplacé dans 3-4 ans…
[^] # Re: Autre réglage possible...
Posté par antistress (site web personnel) . Évalué à 5.
Je n'ai pas l'intention de remplacer mon ssd dans 3-4 ans personnellement, pourquoi le ferais-je ? Tu programmes toi-même l'obsolescence de tes composants ?
La différence de perf reste relative comme toujours, bien sûr. Ce que j'écris dans mon billet c'est que s'il y a un seule réglage à faire, c'est vérifier l'alignement des partitions. Le reste relève de l'optimisation.
Néanmoins compte tenu de la technologie employée, pourquoi ne pas l'épargner avec quelques réglages sans inconvénient (noatime principalement, voire mettre /tmp en tmpfs) et préserver ses performances (trim périodique) ?
[^] # Re: Autre réglage possible...
Posté par MTux . Évalué à 1.
Ce qui me gêne avec la désactivation du noatime c'est que toutes les documentations et tuto t'avertissent que cette fonction ne sert à rien mais peut être quand même utile dans certains cas. Ce genre de phrase n'est pas satisfaisante, soit c'est utile, soit ça l'est pas. La documentation de Fedora a le mérite de citer un logiciel qui en a besoin : mutter.
Donc dans le doute je le laisse, de toutes façons mon idéal c'est quand le système s'adapte automatiquement au matériel, et je pense que Linux (du moins en version récente, comme sur Fedora) en est déjà capable.
L'obsolescence programmée parlons-en, je me suis résigné à remplacer ma machine de 2007 depuis que Gnome2 et KDE3 sont morts, remplacés par des versions sur lesquelles 2GB de ram ne suffisent plus et où un fonctionnement optimal demande un pilote graphique récent.
Et en dehors de cela c'est tout simplement un hobbie pour moi d'upgrader mon matériel pour tester de nouvelles choses ;)
[^] # Re: Autre réglage possible...
Posté par antistress (site web personnel) . Évalué à 4.
noatime est utile si tu as besoin de vérifier si quelqu'un a accédé à tes fichiers. Personnellement, je nen ressens pas le besoin, mais je ne suis pas une agence gouvernementale.
[^] # Re: Autre réglage possible...
Posté par gpe . Évalué à 2.
Ce n'est pas une question d'être une agence gouvernementale ou non. Cette information peut servir à une application (mutt en est un exemple). Mais si noatime pose problème il me semble que de couper la poire en deux avec relatime évite ce problème ?
[^] # Re: Autre réglage possible...
Posté par spider-mario . Évalué à 3.
Pendant des années, j’ai utilisé KDE 4 sur une machine avec 2 Gio de RAM et une carte NVIDIA qui était de l’entrée de gamme en 2006 (une GeForce 7300 GS). Les performances étaient déjà correctes il y a plusieurs versions et elles se sont améliorées au fil du temps. J’aurais du mal à te croire si tu me disais que la version actuelle fonctionne réellement mal.
Je confirme cependant que GNOME Shell n’a pas fonctionné sur cette machine quand j’ai essayé.
[^] # Re: Autre réglage possible...
Posté par FantastIX . Évalué à 3.
Plutôt qu'un gain en performance, j'ai cru comprendre que ça (le noop) évitait de stresser inutilement le CPU.
[^] # Re: Autre réglage possible...
Posté par neil . Évalué à 2. Dernière modification le 11 octobre 2012 à 21:59.
Le wiki de Gentoo suggère que ça dépende du SSD (en gros que pour les Intel X-25, pas bon du tout pour les autres), mais sans vraiment de références.
# SSD vs All-flash systems
Posté par Anonyme . Évalué à 3.
Un peu dérelié, mais intéressant : Pour en lire plus sur la différence entre disques SSD et les All-flash systems (je ne trouve pas comment le dire en français) : http://www.informationweek.com/storage/systems/all-flash-systems-vs-ssd-appliances/240000859
# Très bon test
Posté par hitmanu . Évalué à 1.
Très intéressant ton lien et le test, je le garde sous le coude.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: Très bon test
Posté par antistress (site web personnel) . Évalué à 2.
Merci :-)
# Autre approche avec le SSD sous linux...
Posté par SalvadorDalek . Évalué à 2.
Salut,
une autre option serait de faire du lvm avec auto-tiering:
au sein d'un même VG: avoir un pv sur disque et un pv plus petit sur ssd, et utiliser un daemon genre lvmts pour répartir l'allocation des blocs sur les différents types de disque selon les fréquences d'utilisation…
Avantages:
Inconvénient:
- un peu compliqué à mettre en œuvre
- le ssd est un volume de stockage et le perdre engendre une perte de données (contrairement à un ssd réellement utilisé comme cache)
[^] # Re: Autre approche avec le SSD sous linux...
Posté par SalvadorDalek . Évalué à 2.
J'avais oublié:
Un projet d'auto-tiering pour LVM
https://github.com/tomato42/lvmts
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.