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 #920028.
Run by 
Cette page a été générée par Templeet en 0.1209s (dont 0.0122 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Bon article
La technologie SSD représente définitivement l'avenir du stockage, et cet avenir est relativement proche dans le monde des serveur.
Merci pour cet article qui résume très bien la situation, ça permet d'y voir plus clair =)
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.
[^]Re: Bon article
pour le monde des serveurs, les ssd restent tout de même loin du rapport performances/prix des gros disques durs, surtout quand on parle de performances en écriture (une cache en écriture, c'est sympa si on a le temps de la vider, une écriture continue de volumes dépassant la taille de la cache fait retomber les performances).
Le SSD est surtout intéressant pour le stockage à faible écriture ou les systèmes posant problème à la mécanique, comme les portables.
[^]Re: Bon article
L'articles est effectivement bien fourni en références. Pour les serveurs, une fois la fiabilité de ces "disques" prouvée, les SSD fourniront un impressionnant saut pour les vitesses d'accès. En effet, les serveurs hébergeant de multiples utilisateurs et ceux travaillant en virtualisation ont besoin d'accéder à de nombreux fichiers en même temps.
La somme des temps de mouvement du bras disque dur et d'attente pour trouver le bon secteur sous la tête descendent rarement sous les 10ms. Ces retards deviennent prédominants en charge. Or les SSD annulent ces attentes: pas de mécanique en mouvement.
De plus, les débits de lecture augmentent de mois en mois. En voici un exemple (certes, encore un peu cher pour mon porte-monnaie): http://www.fusionio.com/iodrivedata.pdf . Pour mémoire, le débit d'un bon disque dur dépasse à peine 100MB/s.
Enfin, les tailles des SSD au format 2'1/2 sont en très forte progression: 32GB il y a un an, 320GB aujourd'hui et 1TB annoncé lors du CES de janvier dernier.
Malheureusement, dans ces temps troubles de grosses sociétés possédant des pouvoirs énormes, des nuages s'annoncent: Seagate semble prêt à faire un procès aux fabricants de SSD qui lui feraient de l'ombre: http://www.presence-pc.com/actualite/Seagate-28510/ . So, wait and see...
[^]Re: Bon article
J'avais cependant entendu dire que la principale raison qui faisait que ces systèmes de fichier n'étaient pas plus utilisés etait la présence d'un méchanisme matériel. Ce méchanisme traduit les adresses et permet d'éviter d'utiliser toujours le même bloc pour la même adresse. Le périphérique s'use donc plus uniformément et les mécanismes mis en places au dessus pour faire tourner les adresses utilisées sont rendus inopérents.
Qu'en est-il ? Ces mécanismes vont-ils être supprimés avec l'apparition de FS appropriés ? Ces FS se limitent ils aux cas particuliers de l'embarqué où ces mécanismes sont absents ? Est-ce que l'augmentation de l'espace de stockage rend la création matériele de tels mécanismes plus compliqués ?
[^]Re: Bon article
Qu'en est-il ? Ces mécanismes vont-ils être supprimés avec l'apparition de FS appropriés ?
Probablement, encore faudrait-il que microsoft veuille bien se bouger le cul. Y a qu'à voir tout les APN, Lecteurs mp3 etc tournant encore avec du FAT moisi...
[^]Re: Bon article
L'avantage du FAT c'est que tout le monde le lit..
A quand un système de fichier journalisé normalisé/lisible facilement par tous les OS ?
[^]Re: Bon article
Mouwahahahaha...
Je vois bien un certain OS accepter sans rechigner d'implémenter (correctement et fidèlement) dans son noyau un FS librement documenté, normalisé, afin de faciliter les échanges de données avec les OS concurrents.
Non, là comme ça je ne vois aucune raison qui pousserait l'éditeur dudit OS à refuser de jouer la carte de l'intéropérabilité : c'est pas comme s'ils avaient déjà tout fait pour ne pas le faire, par le passé...
[^]Re: Bon article
C'est justement de que j'essayai de faire remarquer...
D'ailleurs il est amusant de constater que maintenant que ntfs-3g est stable WinFS va sortir (enfin du moins l'éditeur non-susnommé l'a annoncé et garanti qu'il sera meilleur que tous ses concurrents, un petit air de déjà vu tout de même (Piège dans le cyber espace tout ça..).
[^]Re: Bon article
'fin ya eu un joli bout de chemin entre temps : à la sortie de NTFS on avait pas fuse et on avait à peine lufs.
[^]Re: Bon article
WinFS, c'est pas le machin qu'ils ont annoncé comme le gros changement dans longhorn, et qu'ils ont fini par virer pour réussir à n'avoir que 4 ans de retard sur leur roadmap vista ?
Vous devriez vraiment visiter Aperture First !
[^]Re: Bon article
Oui. Et même que finalement, ils ont dit que ça ne servait pas à grand chose et qu'ils allaient ré-intégrer leur travail dans leur équipe de base de donnée ou ailleurs mais peut-être pas dans Windows Longhorn...
http://www.news.com/New-file-system-has-long-road-to-Windows(...)
phil.freehackers.org
[^]Re: Bon article
Mais mon cher tu sais que si tu veux un filesystem specifique dans Windows tu peux le faire toi-meme, l'interface est clairement definie et n'importe qui peut ecrire un driver de filesystem pour Windows. Pas besoin de l'integrer dans le noyau.
Ca a d'ailleurs deja ete fait hein : http://www.fs-driver.org/
Bref, ca serait sympa que tu cherches un peu sur le sujet avant d'accuser MS de qqe chose...
[^]Re: Bon article
Mon cher pBpG, je t'invite à relire mon commentaire...
Tu verras alors que j'ai bien précisé que je ne croyais pas une seule seconde à l'implémentation par MS d'un FS autre que les leurs, dans leur noyau...
Parce que oui, je sais parfaitement qu'on peut rajouter des FS, en témoigne le driver sous XP (et sous Vista ?) permettant de lire (et d'écrire ? je sais plus trop, j'ai pas creusé la question) des partitions ext3 (reconnues cependant comme ext2, me semble-t-il).
Sauf que là, on parle d'un FS qui serait "standardisé" (pourquoi pas un FS existant, d'ailleurs ?) et destiné à remplacer la FAT vieillissante... Idéalement, il serait appréciable que chaque OS le propose nativement (ce qui rendrait donc les choses totalement transparentes pour l'utilisateur), et non devoir passer par une installation, toujours rebutante pour madame Michu.
[^]Re: Bon article
Tiens d'ailleurs c'est quoi les problèmes du FAT 32? Moi les problèmes que j'ai pu avoir :
* copie de fichiers avec des caractères accentués
* copie de fichiers de plus de 4Go (ISO de live-DVD par exemple)
C'est les deux seuls problèmes que m'ont posé ce système de fichier, et vous?
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Bon article
J'y rajouterais la fragmentation et l'absence de journalisation...
[^]Re: Bon article
On peut y ajouter les problèmes de casse des noms de fichiers
[^]Re: Bon article
L'autre avantage est qu'il est extrêmement simple => Facile à implémenter et code minuscule.
Pour l'efficacité, on repassera, mais ça suffit à convaincre pas mal de monde, surtout dans l'embarqué où la taille du code importe.
[^]Re: Bon article
enfin il a mega desaventage ce sont les brevets qui sont dessus quoique sur cela il me semble avoir vu passer que, du moins en Europe, Microsoft s'est fait deboute (a verifier).
[^]Re: Bon article
L'inconvéniant est que personne n'y met de fichier de taille supérieure à 4 Go (image ISO dvd par exemple).
Pour un système de fichier (FS =file system) accessible pour tous les OS, il suffirait que MS décide de supporter les FS issus du libre (la doc n'est pas trop dur à trouver).
Ils pourraient aussi en dire plus de façon ouverte sur leurs FS à eux au lieu de forcer au reverse engineering, mais d'une certaine façon ça les forceraient un peu plus à être performant.
Ce que je trouve intéressant dans cet article, c'est plus d'indiquer des FS appropriés à la technologie utilisée, même s'ils perdent leur généricité (pour des performances accrues sur un disque dur, le système doit par exemple tenir compte des déplacements physiques des têtes de lecture/écriture ce qui n'est pas le cas sur de la mémoire flash).
[^]Re: Bon article
Je ne vois pas le rapport avec le problème de la vitesse d'écriture...
Ce que tu dis concernant la lecture, l'absence de parties mobiles, ... a déjà été dit et redit et je pense que personne ne le remet en cause.
[^]Vitesse d'écriture
note: je n'ai jamais testé les débits ni rien.
Il est possible que sur des machines qui sollicitent beaucoup les disques en écriture, la lenteur actuelle des SSD soit déjà compensée par le fait de ne pas dépenser 10 ms de positionnement des têtes.
Il semble que les SSD "normaux" actuels soient entre 25 et 80 Mo/s en écriture soutenue, et 0,5 ms de délai avant chaque écriture.
Un bon disque SAS 15.000 tours fait aux alentours de 95 Mo/s en lecture/écriture soutenue, et 5 ms de délai avant chaque écriture si on se limite aux premiers 20% de la surface du disque.
Exemple pour 1000 écritures de 1 Mo réparties sur 20% de la surface du disque:
SSD à 25 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 25) = 500 ms + 40 s = 40,5 s
SATA à 65 Mo/s: (1000 x 8ms) + (1000 x 1 / 65) = 8 s + 15,38 s = 23,38 s
SSD à 40 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 40) = 500 ms + 25 s = 25,5 s
SSD à 50 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 50) = 500 ms + 20 s = 20,5 s
SSD à 60 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 60) = 500 ms + 16,7 s = 17,2 s
SAS à 95 Mo/s: (1000 x 5 ms) + (1000 x 1 / 80) = 5 s + 10,5 s = 15,5 s
SSD à 80 Mo/s: (1000 x 0.5 ms) + (1000 x 1 / 80) = 500 ms + 12,5 s = 13 s
Qui a existé en premier: le compilateur ou son code source ?
[^]Re: Vitesse d'écriture
Je crois qu'on a pas les memes sources d'informations en ce qui concerne la vitesse d'un disque SSD.
Cela fait plusieurs mois que je suis un forum sur lequel les geeks en puissance font des benchs avec leurs joujous et bien en raid je vois passer des 400 Mo/s et un disque seul atteint facilement les 100 Mo/s.
http://www.nokytech.net/forum/showthread.php?t=106705&pa(...)
J'envisage d'en acheter un des qu'ils sortent un 64 Go à moins de 1000 euros.
En fait il existe plusieurs technos et si tu suis tout le thread tu auras une vision concrète de ce qui existe et de leurs performances.
[^]Re: Bon article
S'il ne s'agit que de la vitesse d'écriture, le lien fourni (ioDrive) donne 600 MB/s en écriture continue (pas une valeur pic), c'est-à-dire environ six fois la valeur d'un disque dur mécanique. Je crois que cette valeur est optimiste puisque c'est un papier commercial. Ce ne doit pourtant pas non plus être une valeur farfelue.
De toute manière il suffit de suivre les valeurs mois après mois pour les voir s'envoler. Sans doute est-il encore un peu tôt pour jeter les disques durs à la poubelle, mais leurs jours semblent comptés.
Il faut encore attendre une baisse sensible des prix, une levée des incertitudes quant aux brevets éventuellement enfreints, et la montée en performance nettement au dessus de leurs équivalents mécaniques pour que les SSD deviennent une évidence pour tous. La seule inconnue reste: dans combien de temps. À mon avis, trois années suffiront.
[^]Re: Bon article
Un iodrive sur pci-e a 600mB/s qui ne coute pas 2400€ de base, je prends tout de suite (et 16Go me suffise, 32 pour être un peu plus à l'aise)
[^]Re: Bon article
L'articles est effectivement bien fourni en références. Pour les serveurs, une fois la fiabilité de ces "disques" prouvée, les SSD fourniront un impressionnant saut pour les vitesses d'accès. En effet, les serveurs hébergeant de multiples utilisateurs et ceux travaillant en virtualisation ont besoin d'accéder à de nombreux fichiers en même temps.
La somme des temps de mouvement du bras disque dur et d'attente pour trouver le bon secteur sous la tête descendent rarement sous les 10ms. Ces retards deviennent prédominants en charge. Or les SSD annulent ces attentes: pas de mécanique en mouvement.
Faudrait pas oublier que lorsque tu as ce genre d'architecture avec virtualisation et compagnie , tu utilises un SAN derrière ( en FC ou en iscsi , ca dépend du budget ... ) et tu travailles pas sur un seul disque mais des agregats du raid et cie , les débits sont loin de ceux d'un seul disque.
[^]Re: Bon article
"les débits sont loin de ceux d'un seul disque."
Par contre, pour les latences, j'ai très très peur.
[^]Re: Bon article
Par contre, pour les latences, j'ai très très peur.
Ca dépend surtout de la distance entre ta baie et ton serveur , quand c'est de l ordre de la dizaine de metres sur du SAN Fibre Channel c est négligeable ( sur du iSCSI çà se voit deja plus ) , quand t'as des ISLs de plusieurs kilometres , là par contre ...
[^]Re: Bon article
Je ne vois pas en quoi la longueur des cables influes. Le temps de parcours des cables est infimes par rapport au temps de traversé d'un appareil.
[^]Re: Bon article
Le temps de propagation du a la longueurs a peu d'influence, c'est vrai (ex a la louche: 200km a 200000km/s => 1ms, aller-retour 2ms). Mais, lorsqu'il y a de longs cables, il y a affaiblissement et donc des repeteurs, des switchs ou autres au milieu et eux augmentent le delais.
[^]Re: Bon article
les ssd restent tout de même loin du rapport performances/prix des gros disques durs
Si tu veut comparer prix et capacité je te rejoins... mais prix et perfs... j'ai plus de doutes
surtout quand on parle de performances en écriture
Pour toi, un DD va plus vite en écriture qu'un SSD?
une cache en écriture, c'est sympa si
Comme sur un DD...
Il faut comme même faire le ratio entre le nombre de grosses écritures et celles de moindre taille qui tiennent dans le cache...
[^]Re: Bon article
voici un relevé de performances qui montrent que les SSD sont un "peu justes" en performance, surtout en écriture:
www.storagesearch.com/easyco-flashperformance-art.pdf
CKR Solutions Open Source
[^]Re: Bon article
Un peu juste en écriture c'est vite dit. Cela n'est vrai que pour des blocks d'écriture hyper large.
J'avais en tête la taille de bloc de 64K pour avoir la vitesse max d'un disque dure mais vu l'article, il faut plus de 1Mo pour avoir cette vitesse.
Vu les différences de perfs entre SSD et disque dure, cela vaudrait le coup d'avoir un SSD juste pour tout ce qui est plus petit que 1Mo : les metadata et les petits fichiers, et un HD en parallèles pour les gros fichiers. On pourrait utiliser pleinement la bande passante des disques dure et la latence des SSD.
[^]Re: Bon article
EMC ne partage pas ton opinion puisqu'ils commencent à commercialiser leurs premières DMX avec disque SSD.
Les SSD utilisés ont des performances en écriture de l'ordre de 70-80Mo/s ce qui est très honorable et une fois en RAID5 donne des performances satisfaisantes.
Mais c'est surtout sur des applications demandant des latences faibles que ce genre de baies est intéressante, des volumes pour serveurs de fichier, mail ou web. Même pour certaines bases le gain est très important.
[^]Re: Bon article
Que dire de plus comme compliment pour cet article ?
Ha si, que de manière naturelle, tout le monde emploi le terme 'article' et non 'dépêche' ;)
Merci encore