Un petit complément un peu plus orienté sur l'utilisation dans le domaine des flashs dans l'embarqué.
Déja avant de parler des systèmes de fichiers flash, MTD à ses limites :
- pas de support des flashs de plus de 4Go
- pas de support de contrôleur avec dma (en tout cas pas de manière simple)
Ce algorithme est implémenté par les constructeurs de disques SSD dans des microcontrôleurs faisant le lien entre la mémoire flash et l'interface sata. C'est certes transparent pour l'utilisateur mais cela signifie que les systèmes de fichiers traditionnels, avec toutes leurs limitations et tout leur code complexe dédié à la minimisation des temps d'accès par le bras de lecture, vont continuer à être utilisé.
C'est surtout que l'on ne sait pas trop ce qu'il fait et s'il est vraiment robuste. De plus ces algorithmes pour être efficace doivent être optimisé pour certains patterns et donc certains filesystem.
Néanmoins ces disques SSD à base de mémoire flash sont affligés d'un défaut important puisqu'ils ne supportent qu'un nombre restreint de cycles d'écritures (typiquement de l'ordre de 100000).
C'est pire que ça. Là tu parles de la NOR.
Mais c'est de la NAND, où les blocks où l'on écrit les données ne sont pas garanti (sauf le premier). Donc ils peuvent être mauvais en sortie d'usine ou au cours du temps.
Il est donc nécessaire d'utiliser des algos de corrections d'erreur "ecc" pour récupérer les données si le block "fatigue". Il faut aussi être capable de déplacer les données d'un secteur fatigué et de le marqué comme mauvais s'il ne marche plus.
Le gros problème de JFFS2 est qu'il a besoin d'examiner tous les blocs mémoires au moment du montage du système de fichiers afin de construire l'index qui est conservé en RAM.
Il y a le mode sumary qui permet de ne pas examiner tous les blocs mémoires au moment du montage du système. Un résumé est stocké à la fin de chaque "block".
De plus YAFFS fait la même chose (sauf s'il est éteint proprement dans quel cas il sauve un son état en flash).
Un autre problème de jffs2 c'est qu'il est très gourmand en RAM.
YAFFS [...] Ce système a été conçu spécifiquement pour la mémoire flash NAND et il est donc a priori bien adapté aux disques SSD.
Il a les même problème que jffs2 : temps de montage et conso RAM linéaire par rapport a la taille de la flash (la pente est seulement plus faible). Donc non il est pas très adapté au gros média.
De plus ce fs ne gère pas bien la NAND et notamment les bit flips sur les lectures.
PS : les slides présentant yaffs2 et ses évolutions futures sont dispo quelque part sur le net.
UBI et UBIFS Comme cette couche UBI est déjà présente dans le noyau il parait éminemment logique de construire un système de fichiers gérant les disques SSD par dessus cette infrastructure afin de profiter de ses avantages et de factoriser le code noyau
Plus précisément, pour diviser les difficultés celui qui voulait faire jffs3 a développé UBI d'abord, puis UBIFS.
Comme tu le soulignes UBI+UBIFS est très gros. Sera t il simple d'embarquer un support partiel (lecture seul) dans les bootloader ?
Sera t il simple de le garantir sans bug (ou au moins de l'auditer).
Un autre avantage est qu'UBIFS utilise un cache pour les données (writeback) ce qui permet d'éviter d'écrire les données de façon strictement synchrone.
Est-ce un résultat souhaitable sur des périphérique embarqué qui peuvent être éteint n'importe quand ?
De plus tous ces file systèmes sont inadapté dans le cas de disque (ou périphérique) externe : on voudrait par exemple les monter en mass storage partout, ce qui implique l'émulation disque dur et du FAT... Et du coup on est obligé de passé par des flash translation layer qui émule un disque dur sur la flash. C'est ce que l'on trouve dans les SD, clef usb et SDD.
En conclusion pour les SDD il faudra que les fabriquant propose une interface qui permette de desactiver la FTL. Mais cela pose des problèmes.
D'abord ça oblige à creer un nouveau protocole de communication avec ces disques.
De plus ces disques ne seront plus bootable par les bios à moins d'écrire en flash le même format que celui qu'utilise le microcontrôleur du disque...
Enfin les différents constructeurs n'embarque pas forcement le même type de flash et elle ne sont pas cascadé de la même manière, ... Actuellement c'est masqué par la FTL.
Il faudra aussi que des filesystemes flash fasse leur preuve sur les gros média et que MTD soit améliorer.
# Complément...
Posté par M . En réponse à la dépêche Les systèmes de fichiers pour disques SSD. Évalué à 10.
Déja avant de parler des systèmes de fichiers flash, MTD à ses limites :
- pas de support des flashs de plus de 4Go
- pas de support de contrôleur avec dma (en tout cas pas de manière simple)
Ce algorithme est implémenté par les constructeurs de disques SSD dans des microcontrôleurs faisant le lien entre la mémoire flash et l'interface sata. C'est certes transparent pour l'utilisateur mais cela signifie que les systèmes de fichiers traditionnels, avec toutes leurs limitations et tout leur code complexe dédié à la minimisation des temps d'accès par le bras de lecture, vont continuer à être utilisé.
C'est surtout que l'on ne sait pas trop ce qu'il fait et s'il est vraiment robuste. De plus ces algorithmes pour être efficace doivent être optimisé pour certains patterns et donc certains filesystem.
Néanmoins ces disques SSD à base de mémoire flash sont affligés d'un défaut important puisqu'ils ne supportent qu'un nombre restreint de cycles d'écritures (typiquement de l'ordre de 100000).
C'est pire que ça. Là tu parles de la NOR.
Mais c'est de la NAND, où les blocks où l'on écrit les données ne sont pas garanti (sauf le premier). Donc ils peuvent être mauvais en sortie d'usine ou au cours du temps.
Il est donc nécessaire d'utiliser des algos de corrections d'erreur "ecc" pour récupérer les données si le block "fatigue". Il faut aussi être capable de déplacer les données d'un secteur fatigué et de le marqué comme mauvais s'il ne marche plus.
Le gros problème de JFFS2 est qu'il a besoin d'examiner tous les blocs mémoires au moment du montage du système de fichiers afin de construire l'index qui est conservé en RAM.
Il y a le mode sumary qui permet de ne pas examiner tous les blocs mémoires au moment du montage du système. Un résumé est stocké à la fin de chaque "block".
De plus YAFFS fait la même chose (sauf s'il est éteint proprement dans quel cas il sauve un son état en flash).
Un autre problème de jffs2 c'est qu'il est très gourmand en RAM.
YAFFS [...] Ce système a été conçu spécifiquement pour la mémoire flash NAND et il est donc a priori bien adapté aux disques SSD.
Il a les même problème que jffs2 : temps de montage et conso RAM linéaire par rapport a la taille de la flash (la pente est seulement plus faible). Donc non il est pas très adapté au gros média.
De plus ce fs ne gère pas bien la NAND et notamment les bit flips sur les lectures.
PS : les slides présentant yaffs2 et ses évolutions futures sont dispo quelque part sur le net.
LogFS
Il ne gère pas vraiement les NAND pour le moment : http://marc.info/?l=linux-kernel&m=120702790910653&w(...)
UBI et UBIFS
Comme cette couche UBI est déjà présente dans le noyau il parait éminemment logique de construire un système de fichiers gérant les disques SSD par dessus cette infrastructure afin de profiter de ses avantages et de factoriser le code noyau
Plus précisément, pour diviser les difficultés celui qui voulait faire jffs3 a développé UBI d'abord, puis UBIFS.
Comme tu le soulignes UBI+UBIFS est très gros. Sera t il simple d'embarquer un support partiel (lecture seul) dans les bootloader ?
Sera t il simple de le garantir sans bug (ou au moins de l'auditer).
Pour le moment on a pas de benchmark très complet (petite flash/très grosse flash). http://osl.sed.hu/wiki/ubifs/index.php/Mount_results montre des résultats pas terrible.
Un autre avantage est qu'UBIFS utilise un cache pour les données (writeback) ce qui permet d'éviter d'écrire les données de façon strictement synchrone.
Est-ce un résultat souhaitable sur des périphérique embarqué qui peuvent être éteint n'importe quand ?
De plus tous ces file systèmes sont inadapté dans le cas de disque (ou périphérique) externe : on voudrait par exemple les monter en mass storage partout, ce qui implique l'émulation disque dur et du FAT... Et du coup on est obligé de passé par des flash translation layer qui émule un disque dur sur la flash. C'est ce que l'on trouve dans les SD, clef usb et SDD.
En conclusion pour les SDD il faudra que les fabriquant propose une interface qui permette de desactiver la FTL. Mais cela pose des problèmes.
D'abord ça oblige à creer un nouveau protocole de communication avec ces disques.
De plus ces disques ne seront plus bootable par les bios à moins d'écrire en flash le même format que celui qu'utilise le microcontrôleur du disque...
Enfin les différents constructeurs n'embarque pas forcement le même type de flash et elle ne sont pas cascadé de la même manière, ... Actuellement c'est masqué par la FTL.
Il faudra aussi que des filesystemes flash fasse leur preuve sur les gros média et que MTD soit améliorer.