Articles : Les systèmes de fichiers pour disques SSD
Posté par patrick_g (page perso, ). Modéré le 04 avril 2008.
Pourtant cette apparition timide sur le marché n'est que le prélude d'un véritable raz de marée programmé par les industriels dans les années à venir.
Le monde du logiciel libre est-il prêt à exploiter de façon efficace cette nouvelle technologie ? De nouveaux systèmes de fichiers sont-ils nécessaires et le noyau Linux doit-il être adapté ?
Cette dépêche tente de faire le point sur ces questions et d'évaluer les solutions en présence permettant le support des disques SSD.
![[en]](../images/en.png)
Benchmark entre JFFS2, LogFS et UBIFS (2131 hits)-
JFFS2 (314 hits)
-
YAFFS (252 hits)
-
LogFS (242 hits)
-
UBIFS (420 hits)
> Lire la dépêche (96 commentaires, moyenne: 5,1).
Vous avez demandé le commentaire #919806.
Run by 
Cette page a été générée par Templeet en 0.0485s (dont 0.005 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
augmentation du nombre de cycle d'écritures supportés ?
Au lieu de se tordre l'esprit à faire un système de fichier minimisant les écritures, ce qui de toutes façons sera probablement une arlésienne pour la majorité des utilisations serveur (par exemple, par défaut PostgreSQL demande à l'OS de flusher toutes les écritures sur disque, pour minimiser les risques en cas de crash de la machine[1]), n'y a-t-il pas des perspectives d'augmentation du nombre de cycle d'écritures supportées par le hardware, potentiellement moyennant une augmentation raisonnable du prix ? Après tout, on n'en est qu'aux débuts de l'utilisation de cette technologie pour stocker des informations système et données "pérennes" (encore que ce soit un grand mot pour les disques durs, mais enfin, c'est plus pérenne que l'utilisation supposée d'origine des mémoires flash, un support de transport de données ou de stockage pour des périphériques dédiés comme des APN ou des baladeurs), l'utilisation d'une technologie peut couramment influer sur son évolution.
[1] http://www.postgresql.org/docs/8.3/interactive/runtime-confi(...)
[^]Re: augmentation du nombre de cycle d'écritures supportés ?
n'y a-t-il pas des perspectives d'augmentation du nombre de cycle d'écritures supportées par le hardware
Pour le moment, on va vers une baisse de la fiabilité, avec le développement des systèmes nand MLC (plusieurs couches par cellules) qui, pour des raisons de prix, est plus rentable au Go que le SLC (une couche par cellule).
Si on veut utiliser les SSD au mieux de leurs possibilités, il faudra de toutes façons avoir une approche plus intelligente que ce qu'on fait à l'heure actuelle avec les disques classiques. Sinon, la flash en général, à condition de pas trop souvent écrire dessus, c'est un support de stockage presque indestructible.
[^]Re: augmentation du nombre de cycle d'écritures supportés ?
"plusieurs couches par cellules"
Pourquoi couches ? A cause de "layer" ?
C'est des bits. Une cellule flash ou eeprom, c'est un transistor avec une grosse grille. Les charges sont piégé derrière la grille comme pour la DRAM. Sauf que les courant de fuite doivent être infime et avoir une durée de vie supérieur à 64 ms des DRAM :) L'épaisseur d'oxyde est plus importante donc pour chargé, il faut augmenter les tensions (certaines puces Flash contiennent en interne les pompes de charges).
Comme pour les RAM, il y un ampli différentiel pour lire un bit. La différence de potentiel lu est faible quelques centaines de millivolt. Pour éviter les erreurs, il y a plein de bits ECC supplémentaires.
Les MLC utilisent le même principe que ces SLC mais au lieu de gérer 2 niveaux ("layer"...) de tension (0v - qq 100mv), ils gèrent 4 pour pour avoir 2 bits par cellule ou 8 pour 3 bits.
La densité est donc bien plus grande mais la sensibilité aux erreurs aussi.
[^]Re: augmentation du nombre de cycle d'écritures supportés ?
Il ne s'agit pas de minimiser les écritures mais de les répartir équitablement sur l'ensemble de l'espace de stockage.
Je ne vois pas en quoi c'est se tordre l'esprit que de chercher à faire ça.
On le ferait sur un DD si il n'y avait pas de pb de temps d'accès.
Un algorithme de copy on write est toujours bon pour avoir de la journalisation et des snapshots.
Enfin, quel est le problème d'un flush avec ce genre d'algorithme ?
Bref, il est heureux que des gens se creusent la tête pour peut-être voir un jour se généraliser un FS qui soit plus efficace que FAT.