URL: https://linuxfr.org/news/acceleration-ssd-sous-linux Title: Accéleration SSD sous Linux Authors: fcartegnie Davy Defaud et Nÿco Date: 2012年10月09日T19:25:23+02:00 Tags: ssd Score: 28 On trouve certaines offres d’accélération de disque dur par [SSD](http://fr.wikipedia.org/wiki/Solid-state_drive) (_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. ![nimage](http://fcartegnie.free.fr/lines/wp-content/uploads/ssd_slick_drives_remake_icon.png) J’en profite donc pour mettre en forme l’ensemble des informations récoltées depuis un moment. **NdM :** _Merci à_ fcartegnie _pour son journal._ ---- [Journal à l’origine de la dépêche](http://linuxfr.org/users/fcartegnie/journaux/acceleration-ssd-sous-linux) ---- # 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](http://fr.wikipedia.org/wiki/TRIM "Définition Wikipédia") 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](http://fr.wikipedia.org/wiki/Carte_des_p%C3%A9riph%C3%A9riques "Définition Wikipédia") (_device mapper_) et donc le RAID. Linux ne gère le TRIM en [RAID](http://fr.wikipedia.org/wiki/RAID_%28informatique%29 "Définition Wikipédia") 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](http://bcache.evilpiepirate.org/) ## _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](https://github.com/facebook/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](http://tansi.info/hybrid/) 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](http://fcartegnie.free.fr/lines/?p=225).

AltStyle によって変換されたページ (->オリジナル) /