URL: https://linuxfr.org/users/fcartegnie/journaux/acceleration-ssd-sous-linux Title: Accéleration SSD sous Linux Authors: fcartegnie Date: 2012年10月09日T15:56:41+02:00 Tags: ssd Score: 31 ![nimage](http://fcartegnie.free.fr/lines/wp-content/uploads/ssd_slick_drives_remake_icon.png) On trouve certaines offres d'accélération de disque dur par SSD destinées aux OS proprios, et ZFS intègre aussi une solution L2ARC performante et éprouvée depuis un bon moment pour le stockage sous Solaris. Or, du coté de Linux, une solution standard n'existe pas encore. J'en profite donc pour mettre en forme l'ensemble de informations récoltées de puis un moment. Stratégies de cache ----------- - Le **"write-around"**, 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. 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'il ne se trouve pas dans le cache de linux lui même). - **write-through**, le 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. - **write-back**, le cache complet avec buffer 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 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èmatique de libération de blocs et de dégradation de performances est résolue par la commande TRIM sur les SSD directement connectés, mais il faut donc aussi qu'elle soit gérée par le cache. - TRIM over mapper or RAID Même problème pour les device mapper et donc le RAID. Linux ne gère le TRIM en RAID que pour les modes 0/1. - L'amplification en écriture Un des effets connus des disques ne supportant par le TRIM. Voir Wikipedia. - La création de goulet d'étranglement Voir discussion sur bcache Les modules de cache ----------- ### [bcache](http://bcache.evilpiepirate.org/) Linux kernel block layer cache, un candidat sérieux pour être intégré au noyau. 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 IOPS et un ancien SSD SLC en fournit 5000: ça fait une configuration d'1 SSD pour 25 disques durs accélérés... Les moins: - Nécessite de formater spécialement les disques cible (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 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 Le mapper du noyau, pas vraiment prévu 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 repliqué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 un amplification en lecture (aucun bloc libre pour optimisation). - Ne supporte le TRIM qu'à partir de son introduction dans dm, soit 2.6.37 Pour ceux qui préfèrent un résumé sous forme de tableau: [Le même article en Anglais](http://fcartegnie.free.fr/lines/?p=225)

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