La mémoire flash et les systèmes de stockage associés L3 Info. / CDA / IUP Module Architecture & Système 2

Plan Mémoire flash : présentation générale Contraintes et limitations Gestion des contraintes Implémentation des systèmes de gestion

Plan Mémoire flash : présentation générale Contraintes et limitations Gestion des contraintes Implémentation des systèmes de gestion

Présentation générale Systèmes de stockage à base de flash NAND Densité de stockage, résistance aux chocs, faible consommation -> domaine de l’embarqué

Présentation générale Systèmes de stockage à base de flash NAND (2) Embarqué … mais plus seulement : Solid State Drives (SSD) Performances & basse consommation : serveurs, calcul haute performance (HPC) PC de bureau

Présentation générale Localisation dans la classification des mémoires à semi-conducteurs Mémoire non volatile Sous-type d’EEPROM

Présentations générales Principaux types de mémoire flash Flash NAND Coût au bit réduit et densité de stockage élevée Stockage secondaire Accès par blocs Performances lecture / écriture équilibrées Flash NOR Coût au bit élevé -> faible capacité Accès aléatoire Performances : lecture++, écriture-- XIP : eXecute In Place Exécution de code directement depuis la flash sans passer par la RAM BIOS dans les cartes mères, firmwares de périphériques, etc.

Présentations générales Principaux types de mémoire flash (2) Adapté de : NAND vs NOR, Toshiba Inc.

Présentation générale Technologie Transistor à grille flottante Propriété de non volatilité

Présentation générale Micro-architecture : matrice de transistor NAND Transistors montés en série Accès par blocs 1 cellule mémoire Single Level Cell (SLC) : 1 bit Multi Level Cell (MLC) : 2 bits Triple Level Cell (TLC) : 3 bits

Présentation générale Puce flash NAND : architecture interne Opérations : Lecture de page Ecriture de page Effacement de bloc

Présentation générale Puce flash NAND : caractéristiques architecturales

Présentation générale Organisation des puces dans un SSD

Présentation générale Puce flash NAND : Opérations legacy Lecture de page Transfert matrice NAND -> page buffer Puis sortie de la page sur le bus SLC : ~30 µs + E/S MLC : ~30 – 100 µs+ E/S Ecriture de page Réception des données à écrire dans le page buffer Puis transfert dans la matrice NAND SLC : E/S + ~200 µs MLC : E/S + ~300 – 2000 µs Effacement de bloc SLC : 1000 – 2000 µs MLC : 3000 µs Legacy : vs opérations avancés Présentées plus loin

Plan Mémoire flash : présentation générale Contraintes et limitations Gestion des contraintes Implémentation des systèmes de gestion

Contraintes et limitations Contraintes spécifiques à l’utilisation des mémoires flash NAND : Règle Erase-before-write Usure Fiabilité + contraintes sur les opérations avancés Nécessitent la mise en place de systèmes de gestion spécifiques

Contraintes et limitations Contrainte A. : Règle effacer avant d’écrire Pas d’écriture dans une page qui contient déjà des données Il faut au préalable effacer cette page -> problèmes : Or la cible de l’effacement est le bloc complet ! Asymétrie de la granularité des opérations d’écriture et d’effacement Un effacement prend du temps Flash : pas de mise à jour de données sur places (pas d’écrasements)

Contraintes et limitations Contrainte B. : Usure Un bloc ne peut supporter qu’un nombre limité d’effacements Passé un certain seuil il ne peut plus contenir de données Bad Block Présents dès la sortie d’usine Apparaissent au cours de l’utilisation de la puce mémoire Seuil : SLC : 100 000 effacements MLC : 10 000 TLC : 5 000 SLC vs MLC / TLC Compromis performances & durée de vie vs capacité

Contraintes et limitations Contrainte C. : Fiabilité Technologie + fortes tensions appliquées aux cellules : Inversement de bits (bitflips) sur les données stockés / lues / écrites en flash Rétention : 5 à 10 ans Peut baisser à 1 an pour des puces en fin de vie (nombreux effacements subits) Source : http://www.snia.org/sites/default/education/tutorials/2009/spring/solid/JonathanThatcher_NandFlash_SolidState_Storage_ReliabilityV1-0-nc.pdf

Contraintes et limitations Opérations avancées et contraintes associées Opérations legacy : supportées par toutes les puces flash Contrainte sur les opérations effacer avant d’écrire Opérations avancés Supportées par certaines puces flash et certaines architectures de stockage (SSD) Contraintes associés

Contraintes et limitations Opérations avancées et contraintes : mode cache Cache buffer : pipeline transfert matrice <-> cache buffer et page buffer <-> bus E/S Contraintes : accès séquentiel, même plan

Contraintes et limitations Opérations avancées et contraintes : mode cache (2)

Contraintes et limitations Opérations avancées et contraintes : copy-back Transfert interne, des données d’une page à une autre, au sein d’un même plan Contraintes Index page source & cible : Tous les deux pairs ou tous les deux impairs Même plan

Contraintes et limitations Opérations avancées et contraintes : opérations multi-plans Opérations sur tous les plans d’un même die (~= puce) Même adresse à l’intérieur du plan pour les pages / blocs ciblés

Contraintes et limitations Opérations avancées et contraintes : opérations multi-plans (2)

Contraintes et limitations Opérations avancées et contraintes : architecture NAND SSD Opérations puce-entrelacée et multi-canaux

Plan Mémoire flash : présentation générale Contraintes et limitations Gestion des contraintes Implémentation des systèmes de gestion

Gestion des contraintes Limitations de base et contraintes des opérations legacy : Règle effacer avant d’écrire Usure Fiabilité Systèmes de gestion pour mémoire flash qui gèrent les contraintes et les limitations : « Couche de gestion » Pour permettre l’utilisation de la mémoire flash dans les systèmes informatique Dans cette partie du cours : principes globaux Partie suivante : exemples concrets d’implémentations

Gestion des contraintes Gestion de la règle « effacement avant écriture » Règle effacer avant d’écrire : Du point de vue flash : Pas d’écriture dans une page qui contient déjà des donnés -> Pas de mise à jour de données sur place Du point de vue du système d’exploitation : On s’attend à pouvoir écraser des donnés ! Solution : traduction d’adresse logiques vers physiques Adresses logiques : adresses vues par l’OS / l’applicatif Adresses physiques : pages / blocs flash

Gestion des contraintes Traduction d’adresses : fonctionnement Introduction d’un nouvel état pour les pages Libre Occupée (valide) Occupée (invalide)

Gestion des contraintes Ramasse-miettes (garbage collector)

Gestion des contraintes Ramasse-miettes (2)

Gestion des contraintes Ramasse-miettes (2) Politique de choix du bloc victime Greedy : Choix du bloc avec le plus de pages invalide Bonnes performances car moins de recopies de données toujours valide Ne prend pas en compte l’usure des blocs Coût / Bénéfice : Calcule un score pour chaque bloc : Usure : compteur d’effacement, fréquence d’utilisation, temps depuis la dernière utilisation

Gestion des contraintes Usure Répartition de l’usure Distribution des cycles d’écriture / effacement sur l’intégralité des blocs de la mémoire flash Pour en maximiser la durée de vie On souhaite éviter que certains blocs s’usent avant d’autres Objectif : réduire l’écart entre les compteurs d’effacements des blocs Peut être mise en œuvre à différents niveaux : Dans la stratégie d’écriture (allocation des pages à écrire) Au niveau du choix du bloc victime du GC Via certains mécanismes spécifiques Séparation données chaudes / froides et déplacement des données chaudes à intervalles réguliers Marquage et gestion des bad blocks

Gestion des contraintes Répartition de l’usure - exemple

Gestion des contraintes Fiabilité Utilisation de codes correcteurs d’erreurs Ajout de méta-données dans la zone OOB Détection et recouvrement d’erreur de lecture / écriture (bitflips) Bloc Page OOB Types de codes utilisés : Hamming (SLC): Détecte 2 erreur / corrige 1 erreur par page Impléméntation simple Reed-Solomon, Bose-Chaudhuri-Hocquenghem (MLC/TLC) : Détecte et corrige plusieurs erreurs par page Mise en œuvre plus complexe Codes implémentés en logiciel (OS hôte) ou en matériel (circuit dédié

Gestion des contraintes Conclusion Effacement avant écriture Traduction d’adresses logiques vers physiques Mises à jour de données physiquement hors place Etat invalide Ramasse-miettes Usure Répartition de l’usure Fiabilité Codes correcteurs d’erreurs

Plan Mémoire flash : présentation générale Contraintes et limitations Gestion des contraintes Implémentation des systèmes de gestion

Flash Translation Layer (FTL) Systèmes de gestion Deux grandes classes Flash Translation Layer (FTL) Flash File Systems (FFS) (systèmes de fichiers dédiés)

Systèmes de gestion : FTL Présentation générale Algorithmes de gestion flash implémentés dans le contrôleur de périphérique à base de mémoire flash Solution matérielle + logicielle Emule un disque dur Couche d’abstraction

Systèmes de gestion : FTL Présentation générale (2) Nécessite une certaine quantité de mémoire vive pour fonctionner SRAM interne à la puce FTL ou DRAM externe (SSD) Performantes mais coûteuses par rapport à la flash Pour stocker des méta-données Notamment les tables de traduction d’adresses DRAM dans les SSD : cache de données On classifie les FTL selon la granularité de la traduction d’adresse : Page, bloc ou hybride

Systèmes de gestion : FTL Traduction par page Chaque page logique peut correspondre à n’importe quelle page physique Granularité fine : flexible et performant

Systèmes de gestion : FTL Traduction par page (2) Une entrée dans la table par page flash gérée Grande taille de table

Systèmes de gestion : FTL Traduction par page (3) Taille de la table : la traduction par page pure n’est pas utilisée en pratique

Systèmes de gestion : FTL Traduction par bloc Granularité : bloc Conservation de l’offset d’une page dans le bloc contenant lors de la traduction d’adresse

Systèmes de gestion : FTL Traduction par bloc (2) Taille de table réduite : une entrée par bloc

Systèmes de gestion : FTL Traduction par bloc (3) Problème de performances : un effacement + recopie d’un bloc complet à chaque mise à jour de données Traduction par bloc inutilisable en environnement réel

Systèmes de gestion : FTL Traduction hybride Tente de profiter des avantages des deux types de traduction Performances et taille de table de traduction Beaucoup de systèmes actuels sont à base de traduction hybride Nombreuses implémentations différentes Espace flash géré Bloc de log : traduit par page Bloc de données : traduit par bloc

Systèmes de gestion : FTL Traduction hybride (2) Rôle des blocs de log : Recevoir les écritures (notamment aléatoires / bursts) Lorsqu’il n’y a plus de blocs de log disponible : Il faut transformer les blocs de log en blocs de données et effacer des blocs de données pour créer de nouveaux blocs de log libres Ramasse-miettes : fusions Rappel : Page logique : n’importe où dans les blocs de log (trad. par page) … … mais conservation de l’offset dans le bloc de donnée correspondant 3 types de fusions selon les situations, plus où moins coûteuses en nombre d’accès flash

Systèmes de gestion : FTL Traduction hybride : fusion par commutation Switch merge Conservation de l’offset OK et pages logiques présentes séquentiellement dans le bloc de log victime Commutation directe du bloc de log en bloc de données Rapide : un unique effacement (ancien bloc de données)

Systèmes de gestion : FTL Traduction hybride : fusion partielle Partial merge Conservation de l’offset OK et pages logiques présentes séquentiellement dans le bloc de log victime Vrai pour un sous-ensemble des pages du bloc Le reste sont des pages libres Recopie des pages depuis l’ancien bloc de données puis effacement Coût moyen

Systèmes de gestion : FTL Traduction hybride : fusion complète Full merge Pages dans le bloc de log victime proviennent de blocs logiques différents Multiples recopies depuis les blocs de données concernés Coût très élevé : plusieurs lectures / écritures / effacement pour libérer un bloc

Systèmes de gestion : FTL Traduction hybride : fusion complète

Systèmes de gestion : FTL Exemple de FTL tirées de la littérature DFTL : Demand-Based Flash Translation Layer FTL à base de mapping par page Table de mapping stockée et maintenue en majorité sur la flash Cache de traduction d’adresse en mémoire vive FAST : Fully Associative Sector Translation A base de mapping hybride Un bloc reçoit les accès séquentiels pour maximiser les chances de fusion par commutation En pratique, dans les périphériques actuels: FTL -> boîte noire propriétaire, difficile de connaître son fonctionnement Aayush Gupta, Youngjae Kim, and Bhuvan Urgaonkar. 2009. DFTL: a flash translation layer employing demand-based selective caching of page-level address mappings. In Proceedings of the 14th international conference on Architectural support for programming languages and operating systems (ASPLOS XIV). ACM, New York, NY, USA, 229-240. DOI=10.1145/1508244.1508271 http://doi.acm.org/10.1145/1508244.1508271 Chien-Yu Liu; Ying-Shiuan Pan; Hsin-Hung Chen; Ying-Chih Wu; Da-Wei Chang, "Techniques for improving performance of the FAST (fully-associative sector translation) flash translation layer," Consumer Electronics, IEEE Transactions on , vol.57, no.4, pp.1740,1748, November 2011

Flash Translation Layer (FTL) Systèmes de gestion Deux grandes classes Flash Translation Layer (FTL) Flash File Systems (FFS) (systèmes de fichiers dédiés)

Systèmes de gestion : FFS Flash File Systems Systèmes de fichiers dédiés aux mémoires flash OS OS Système de fichiers Pour HDD (FAT, NTFS, …) FFS (JFFS2, …) R W R W E FTL Flash R W E Flash Logiciel Matériel

Systèmes de gestion : FFS Présentation générale Solution purement logicielle : FFS implémenté dans le système d’exploitation Gèrent des puces flash directement soudées sur la carte mère FFS propres au domaine de l’embarqué Rôles : Gestion du stockage & contraintes flash Gestion des contraintes propres à l’embarqué Gestion du système de fichiers proprement dit Exemples : JFFS2, YAFFS2, UBIFS

Systèmes de gestion : FFS Rôle des FFS : Gestion stockage & contraintes flash Traduction d’adresses, répartition de l’usure, codes correcteurs d’erreurs Principe général pour la traduction d’adresses :

Systèmes de gestion : FFS Rôle des FFS : Contraintes de l’embarqué et passage à l’échelle Ressources limitées (CPU, RAM) Tolérance aux démontages brutaux (coupures de courant) Journalisation, logs, opérations atomiques Passage à l’échelle (scalabilité) Comment évoluent le temps de montage et la consommation RAM du FFS lorsque l’on augmente l’espace flash géré ? Linéaire ? Logarithmique ?

Systèmes de gestion : FFS Rôle des FFS : scalabilité de l’empreinte RAM JFFS2 UBIFS Scalabilité linéaire Scalabilité logarithmique Il en est de même pour le temps de montage : JFFS2 est inutilisable avec des puces flash de taille > 512 MB http://elinux.org/Flash_Filesystem_Benchmarks_Kernel_Evolution

Systèmes de gestion : FFS Intégration des FFS sous Linux L’OS Linux supporte les FFS les plus populaires (JFFS2, YAFFS2, UBIFS)

Systèmes de gestion : FFS Le système de fichier virtuel Situé en amont du FFS Couche d’abstraction pour tous les systèmes de fichiers supportés par Linux Maintient un cache de donnée, le page cache Tamponne tous les accès aux fichiers en RAM -> http://www.linuxatemyram.com/ Mécanismes associés : Pré-chargement (Read-ahead) Ecriture différée (Write-back)

Systèmes de gestion : FFS Le pilote NAND générique MTD Memory Technology Device

Systèmes de gestion : FFS JFFS2 2001 (Linux 2.4.10) mature Ecritures empaquetées dans des nodes stockées en flash Indexation : table Scan total de la flash au montage pour reconstruire la table -> 15 Minutes pour monter une partition de 1 GB Scalabilité linéaire Ramasse-miettes : listes de blocs Victime : bloc avec beaucoup de donénes invalides Répartition de l’usure : 1 fois sur 100 -> bloc complètement valide

Systèmes de gestion : FFS YAFFS2 Date de 2002 Utilisé dans l’OS Android (Linux) Données découpées en “chunks” Taille : une page flash sous-jacente Indexation : table -> scalabilité linéaire

Systèmes de gestion : FFS UBIFS 2008 (Linux 2.6.27) Indexation : arbre (stocké en flash) Seulement un sous-ensemble en RAM Ramené à la demande Scalabilité logarithmique Pas de mises à jour de données sur place en flash (contrainte) Arbre itinérant

Systèmes de gestion : FFS UBIFS : arbre itinérant « Wandering tree »

Systèmes de gestion : FFS JFFS2 vs YAFFS2 vs UBIFS

Conclusion Mémoire flash NAND Contraintes spécifiques Principal média de stockage secondaire dans l’embarqué De plus en plus présente dans les autres domaines : PC de bureau, serveurs, HPC Contraintes spécifiques Systèmes de gestion relativement complexes

Conclusion http://www.ece.umd.edu/~blj/CS-590.26/micron-tn2919.pdf

Conclusion http://forwardthinking.pcmag.com/none/306684-storage-visions-petabytes-are-the-new-terabytes