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
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
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
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 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
# bcache ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
bcache semble bientôt attendre le kernel. Je n'ai pas vu si il était possible d'utiliser plusieurs SSD comme cache, après tout la téchnologie existe depuis quelques années et il est possible de trouver des SSD de 16 Go devenu trop petit même pour un disque système (ssd sur "/" et "/home" sur un hd).
"La première sécurité est la liberté"
# HammerFS
Posté par barmic . Évalué à 2.
Pour dm_mod :
Je vois pas en quoi c'est un problème. Certaines distributions comme Debian stable proposent un noyau 2.6.32, mais je ne suis pas sûr que ce soit les utilisateurs cible.
Tu as oublié je crois de parler de HammerFS qui écris les méta-données sur le SSD.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HammerFS
Posté par fcartegnie . Évalué à 3.
Ce ne sont pas les données et depuis ext3 tu peux aussi écrire ton journal sur un volume séparé.
[^] # Re: HammerFS
Posté par barmic . Évalué à 2.
En tout cas c'est une approche qui me semble intéressantes pour des SSD rapide mais petits avec de gros volumes de données. Ça ne rend pas les lectures plus rapides, ça les réduit juste leur latence.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HammerFS
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 09 octobre 2012 à 22:41.
C'est un peu l'impression que ça me donne. Du gros bullshit qu'on pourrait résumer par "tout existe, ou l'équivalent, à la charge de l'admin de le mettre en place, selon des contraintes perso ou pro". L'impression d'un "nom / marque" faisant automatiquement ce qu'on peut déjà faire par ailleurs. Ouhai j'vais faire du ssd cache, top moumoutte, c'est une option directe" oupss
[^] # Re: HammerFS
Posté par benja . Évalué à 2.
En fait si, il s'agit bien aussi des données (cache). Cf. http://www.dragonflybsd.org/features/#index6h2
« This DragonFly feature allows SSD-configured swap to also be used to cache clean filesystem data and meta-data. The feature is carefully managed to maximize the write endurance of the SSD. […] »
# Accélération par carte RAID également.
Posté par Damien Thébault . Évalué à 8.
Je pense qu'il est intéressant de mentionner que certaines cartes raid permettent également d'avoir un cache SSD de manière transparente du point de vue de l'OS.
Par exemple maxCache chez Adaptec ou CacheCade chez LSI.
# Intérêt limité ?
Posté par moi1392 . Évalué à 4.
Le cache disque en mémoire étant déjà présent et les mémoire de plus en plus grande.
Au boulot (j'ai une grosse machine), absolument tous mes accès disques sont en cache, il n'y a que les premiers accès qui sont longs.
Quel est donc l'intérêt de ce genre de solutions ?
Pour les serveurs qui gèrent énormément de requetes sur de très très grosses bases de données ?
On ne peut pas simplement leur mettre plus de mémoire ? Le coût n'est pas si exorbitant au final, et la différence entre un accès en cache mémoire et un en cache ssd est quand même énorme !
Ou alors pour des machines un peu plus anciennes qui ne gèrent pas de grosses quantités de mémoire ?
[^] # Re: Intérêt limité ?
Posté par Kioob (site web personnel) . Évalué à 2.
Le problème ne vient pas tellement des lectures, mais surtout des écritures : la plupart des disques classiques plafonnent à 150/200 IO par seconde, si bien que si on écrit aléatoirement plein de blocs de 4Ko on va plafonner à 800Ko/s d'écriture, très loin des 100Mo/s (et plus) annoncé pour le disque.
Dans le cas du mode «write-back», le SSD va pouvoir écrire tout ça rapidement, ce qui laissera le temps au système d'agglomérer les blocs pour ensuite les écrire vers les disques si «lents».
Et pour moi le cache de lecture «write-throught» a le même but : on allège les disques de quelques accès, afin qu'ils se concentrent sur les écritures qu'ils ont tant de mal à gérer.
D'où l'approche de systèmes tels que zfs et btrfs qui privilégient largement les écritures sur les lectures : c'est à dire que la plupart des écritures sont séquentielles, au prix d'une forte fragmentation sur les lectures.
Après ça dépend très probablement des charges des systèmes, mais de ce que je vois chez les clients les lectures posent rarement problème (comme tu dis il suffit souvent d'ajouter de la mémoire), contrairement aux écritures.
alf.life
[^] # Re: Intérêt limité ?
Posté par moi1392 . Évalué à 2.
C'est vrai que je connais plutôt mal le problème des écritures. N'hésite pas à me reprendre si je dis des bêtises.
Je suppose qu'on ne peut pas se permettre de garder trop longtemps en cache mémoire seulement une page à écrire, pour éviter une perte de données en cas de plantage ou coupure de courant.
Il peut y avoir aussi d'autres problèmes difficiles à gérer, comme quand le disque est presque plein, et qu'au moment de l'écriture effective, on trouve plusieurs secteurs défectueux, dans ce cas là, on n'est plus en mesure de tout écrire, alors qu'on a annoncé que c'était le cas.
Je suppose donc que dans ce cas, un cache SSD fait office de cache disque non volatile et peut-être pertinent (quoi que je ne voit pas comment il peut aider dans le cas du disque "plein par surprise" comme diraient les suèdois)
[^] # Re: Intérêt limité ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2. Dernière modification le 11 octobre 2012 à 10:14.
La gestion des secteurs défectueux est automatiquement fait par le disque lui-même.
Il y a surtout le problème du fsync() demandé bien trop souvent, qui oblige a envoyer tout sur disque avant de continuer l’exécution du programme. Cela peut geler une interface, Firefox a eu le problème. Souvent un simple fdone() ferait l'affaire.
Les écritures nécessitent d'être sécurisées sur un support qui supporte la perte du courant ou un gros crash système. Le cache en RAM ne peut pas servir à ça, sans compromettre la sécurité des donnés.
Il y a une expérience assez marrante à faire : c'est le fameux laptop mode. L'écriture sur disque périodique est a mettre à 25s au lieu des 3 secondes habituels. On peut aussi désactivé le fsync() mais cela nécessite un patch kernel (ou une option dans /proc ?). Avec ce genre de modification, le PC a l'air de voler.
"La première sécurité est la liberté"
[^] # Re: Intérêt limité ?
Posté par steph1978 . Évalué à 2.
Je vois quelques avantages au ssd par rapport à la ram:
- le cache ram est utile en lecture mais les écritures doivent passer par le disque dur
- le ssd persiste les données même en cas d'arrêt du système
- à 150€ la barette de 8GB de RAM qualité serveur, 128GB couteront dans les 2400€; alors qu'un SSD 128GB coutera moins de 400€.
[^] # Re: Intérêt limité ?
Posté par moi1392 . Évalué à 1.
Je suis d'accord sur ces 2 points, même si pour moi c'est le même problème, il FAUT passer par le disque pour ne pas perdre de données en cas de plantage/arrêt du système.
Celui là un peu moins, des machines avec beaucoup de ram, on en trouve pas si cher.
Chez nous les machines de renouvellement actuelles ont 192 Go de Ram, et on ne les paye pas "énormément" cher, en tous cas, si la ram seule coutait 2400 €, j'imagine même pas les machines complètes !!!
Et puis pour ceux qui veulent vraiment des performances en lecture, je pense qu'ils ont les moyens de mettre ce genre de prix pour avoir de la mémoire.
Pour les autres, un ssd de 128 Go c'est pour installer son système, pas faire un cache disque.
[^] # Re: Intérêt limité ?
Posté par steph1978 . Évalué à 2.
Je me basais sur des éléments issues du même catalogue fournisseur.
Et je te confirme que dans mon cas, la RAM représente environ deux mille euros.
Qu'est ce que tu veux dire par "un ssd de 128 Go c'est pour installer son système, pas faire un cache disque" ? Il faut plus gros ?
[^] # Re: Intérêt limité ?
Posté par moi1392 . Évalué à 1. Dernière modification le 12 octobre 2012 à 17:29.
Même à 2000€, je ne trouve pas ça excessif du tout pour une boite pour les services critiques.
Après encore une fois, c'est sur que s'il y a beaucoup d'écritures, c'est pas pareil…
Tiens d'ailleurs, il me semble que google publie de temps en temps des stats sur ses serveurs, ça serait intéressant de savoir quels quantités de ram ils mettent sur le machines et les taux de réussite/manque du cache mémoire pour les accès disques. Car à priori, pour tout ce qui est requêtes, c'est purement de l'accès en lecture.
Après, ça serait cool de savoir aussi s'ils envisagent de mettre en place ce genre de solutions pour la partie référencement, enregistrement des données collectées, …
non, c'est juste qu'un particulier, en général, quand il achète un ssd, il s'en sert pour installer son système.
# Cache dans le noyau
Posté par Pierre Roc . Évalué à -1.
Bonjour,
Je ne sais s’il y a encore grand monde qui suis ce journal. Mais je tente tout de même.
Suite à la mise à jour ce matin de ma gentoo, j’ai vu apparaître une nouvelle option dans le menuconfig du kernel (3.5.7 en lui et place du 3.3.8)
Cette option permet d’utiliser un système de fichier comme cache d’un autre. Elle est pensée à priori pour les systèmes de fichiers montés à distance. Quelqu’un a essayé avec une configuration SSD+disque dur ? Cela pourrait être intéressant…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.