Les systèmes de fichiers pour disques SSD

Posté par (page perso) . Modéré par Christophe Guilloux.
Tags :
4
4
avr.
2008
Technologie
Depuis plusieurs mois les disques durs basés sur de la mémoire flash, aussi nommés disques SSD, commencent à apparaître dans des machines comme l'EeePC d'Asus ou le MacBook Air d'Apple. De plus il est possible d'acheter ces disques séparément pour les installer dans des ordinateurs de bureau afin d'augmenter leurs performances.
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. Un disque dur classique est constitué d'un bras de lecture survolant à très courte distance un plateau rotatif magnétisé et tournant à plusieurs milliers de tours par minute. On voit immédiatement tous les inconvénients de cette technologie: la résistance aux chocs est faible car un contact entre le bras et le plateau doit être évité à tout prix. D'autre part la fiabilité et la consommation énergétique sont mauvaises car il y a des pièces mécaniques à mettre en mouvement. Enfin l'accès aux données est lent car le bras de lecture doit se repositionner au dessus des données avant de pouvoir les lire.
La promesse des disques SSD est de s'affranchir de tous ces défauts d'un seul coup. En basculant vers cette nouvelle technologie qui ne comporte pas de pièces en mouvement on obtiendrait une bonne résistance aux chocs, une fiabilité de haut niveau, une consommation réduite et des temps d'accès sans commune mesure avec les disques durs traditionnels.

Pourtant, outre l'obstacle du prix et de la capacité, il reste un problème important à résoudre afin de profiter pleinement de tous ces avantages. En effet les systèmes de fichiers utilisés jusqu'à présent ont tous été conçus avec les limitations des disques durs en tête et une bonne partie de leur architecture est à revoir.
Actuellement les disques SSD utilisent une interface de communication standard (souvent l'interface SATA) et ils sont vu par le système d'exploitation comme des disques durs classiques. Cela leur permet d'être formaté avec un système de fichiers normal et d'être inséré dans une machine sans problème en dépit du fait qu'ils ne comportent pas des secteurs mais des blocs mémoires.
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).
Pour faire face à ce problème la technique du "wear levelling" a été développée. Elle consiste schématiquement à enregistrer le nombre d'écritures pour chaque bloc mémoire et à répartir ensuite intelligemment les nouvelles données à écrire de façon à minimiser l'usure de chaque bloc. Des graphiques présentant l'évolution de l'usure d'un disque SSD avec et sans wear levelling sont disponibles sur cette page.
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é.

Il est donc bien plus efficace de créer des systèmes de fichiers spécialement dédiés aux disques SSD et dialoguant directement avec la puce de mémoire flash sans passer par le microcontrôleur de wear levelling. Cet algorithme est ainsi implémenté directement dans le système de fichiers optimisé pour les SSD.
C'est pourquoi de nombreux développeurs du monde du logiciel libre se sont lancés dans la conception de nouveaux systèmes de fichiers spécialisés dans les disques SSD. Comme il est de mise dans le monde de Linux la compétition est rude et tous les projets aspirent à devenir le Ext3 de demain. A ce stade de développement il peut être intéressant de passer en revue les concurrents en lice et d'évaluer leurs chances respectives.

JFFS et JFFS2

Le système JFFS (Journaling Flash File System), disponible sous licence GPL, a été écrit à l'origine par la société Axis Communications pour l'antique noyau Linux 2.0. Il a été remplacé par JFFS2 qui, sous les auspices de Red Hat et toujours sous licence GPL, a fait son entrée dans le noyau 2.4.10 en septembre 2001. C'est donc un système vraiment mature qui, malgré des limitations que nous verrons par la suite, représente un choix sans risques.
Alors que JFFS première mouture ne fonctionnait qu'avec les mémoires flash NOR et utilisait un mode d'écriture purement circulaire, JFFS2 propose un système bien plus abouti. Tout d'abord la compatibilité avec la mémoire flash NAND, mieux adaptée au stockage d'informations, est assurée. Ensuite les données peuvent être compressées (avec plusieurs algorithmes au choix) ce qui est précieux car les disques SSD ont des capacités de stockage inférieures aux disques durs classiques. Enfin JFFS2 ne fonctionne pas sur un mode d'écriture circulaire comme le faisait JFFS. Avec ce système toutes les écritures s'empilent dans une queue qui écrit en parcourant progressivement tout l'espace disque. C'est une solution simple mais qui implique que toutes les données du disque sont réécrites (même si cela n'était pas nécessaire) et que cela diminue la longévité du disque. Au contraire JFFS2 traite les données par blocs et évite de toucher aux données statiques sur le disque. Comme les blocs mémoires d'un disque SSD sont de grandes tailles (32 Ko ou plus) un ramasse-miettes (garbage collector) est utilisé pour récupérer de la place en fusionnant les données dans des nouveaux blocs afin que les anciens puissent libérer de la place.
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. Si cette opération n'est que peu pénalisante dans le cas d'un volume de petite taille, elle devient absolument rédhibitoire avec les disques SSD modernes (8 Go et plus).
En définitive JFFS2 est un bon système de fichiers et il est bien adapté aux disques flash de faible capacité mais, du fait de son temps de montage et de l'ancienneté de sa conception, il ne peut plus être considéré comme une solution à privilégier. Le monde du libre a clairement besoin d'un remplaçant.

YAFFS et YAFFS2

Une alternative est le système de fichiers YAFFS (Yet Another Flash File System) développé sous double licence (GPL/commercial) par la société Aleph One. 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. On peut noter d'autre part que YAFFS a été conçu de façon modulaire afin qu'il puisse être utilisé avec d'autres systèmes d'exploitation (par exemple Microsoft WindowsCE).
Une seconde version, YAFFS2, a été introduite afin de respecter la nécessité de n'écrire que le moins de fois possible sur les blocs mémoires et pour permettre l'accès à la mémoire NOR.
YAFFS est presque aussi ancien que JFFS2 puisque l'ouverture du CVS date de mai 2002 mais ce système de fichiers n'a jamais vraiment "décollé" dans le monde du libre. La société Aleph One semble vraiment réserver son produit pour le monde de l'embarqué et n'a jamais vraiment cherché à bâtir une communauté de développement. Un des gros problèmes de YAFFS est le fait qu'il n'est pas intégré dans la branche principale du noyau Linux et qu'il n'y a jamais eu de tentative d'inclusion. Pour pouvoir utiliser ce système il est donc nécessaire de le compiler à partir des sources et la documentation n'est pas vraiment à jour. Bien entendu l'évolution rapide du noyau signifie que les risques de non compatibilité avec un système de fichiers externe comme YAFFS sont élevés comme cet exemple le prouve.

LogFS

Un autre système de fichiers libre (sous licence GPL) et spécialisé dans la mémoire Flash est également développé dans la perspective de l'arrivée en masse des disques durs de type SSD. LogFS est écrit principalement par Jörn Engel et il est basé sur une écriture séquentielle des données (log-structured approach) qui ne nécessite pas de scan complet du volume au montage. Toute la structure du système de fichiers est donc écrite directement dans le disque ce qui accélère considérablement le montage par rapport à JFFS2. Selon Jörn Engel, sur un disque NAND flash d'une capacité de 1 Go, on passe de 3,3 secondes pour le montage sous JFFS2 à 60 millisecondes avec LogFS.
En dépit de ces promesses, l'écriture de LogFS n'est pas réellement terminée et le travail avance lentement puisque Jörn est le seul vrai contributeur. Tant qu'il n'y avait pas de concurrent sérieux pour le titre de "système de fichiers de nouvelle génération pour disques SSD", LogFS pouvait représenter l'avenir (voir cet article de mai 2007). Mais il semble que ce ne soit plus le cas puisqu'un rival très sérieux, UBIFS, vient d'apparaitre récemment.

UBI et UBIFS

UBI (Unsorted Block Images) est une couche d'abstraction présente dans le noyau Linux depuis la version 2.6.22 et qui permet de gérer les périphériques à base de mémoire NAND flash. C'est un équivalent fonctionnel de LVM mais spécialisé dans la mémoire flash. UBI effectue un mappage entre les blocs logiques de la mémoire flash et les blocs physiques. Elle permet la répartition des écritures sur toute la mémoire (wear levelling) et elle tient compte des blocs mémoires défectueux (bad-block handling). La couche gère également la création de volumes UBI qui peuvent être dynamiquement créés, re-dimensionnés ou supprimés. Un fichier PDF complet sur la conception d'UBI est disponible ici.
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 :

          ===========================
         | Système de fichiers UBIFS |
          ===========================
                        |
      =====================================
     | Couche UBI de factorisation de code |
      =====================================
                        |
        =============================
       | Couche MTD interne au noyau |
        =============================
                        |
      _________________________________
     |       |           |             |
 ======    =====    ===========    =========
| NAND |  | NOR |  | DataFlash |  | ECC NOR |
 ======    =====    ===========    =========


Les ingénieurs de la firme Nokia, en collaboration avec l'université de Szeged, ont donc travaillé afin de développer UBIFS (UBI file system) et ont récemment présenté le résultat de leurs efforts sur la liste de diffusion du noyau.
Comme pour LogFS, il a été décidé de conserver sur le disque Flash l'index de la structure du système de fichiers afin d'éviter de lire l'intégralité du disque. L'ennui c'est qu'un scan de tout le disque est quand même nécessaire lors du montage car la couche UBI en a besoin pour attacher le périphérique. Cependant ce scan se contente de lire les en-tête des blocs les temps de boot sont donc bien plus rapides qu'avec JFFS2.
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. Le gain en performances est absolument ahurissant (write tests gave us ~100 times faster performance which is clearly because of the caching) par rapport à l'écriture synchrone de JFFS2.
Enfin UBIFS, ou plutôt la couche UBI sous-jacente, gère parfaitement le dysfonctionnement des blocs mémoires (courant avec la mémoire flash) que ce soit lors de la création du système de fichiers ou au cours de la vie du système. LogFS est limité à la gestion des mauvais blocs lors de la création et ne peut les gérer par la suite.
Un document détaillé sur le design d'UBIFS est disponible ici.

En conclusion

JFFS2 est âgé et son temps de montage le rend inadapté pour utiliser les disques modernes de grande taille. YAFFS2 est un bon système pour l'embarqué mais il reste relativement obscur et ne vise pas à intégrer Linux. En définitive il ne reste vraiment en lice que LogFS et UBIFS.
Par rapport à son nouveau concurrent LogFS garde l'avantage sur le plan de la compacité du code (environ 8000 lignes contre 11000+30000 pour UBI+UBIFS) et sur le temps de montage. Néanmoins la situation a beaucoup changé et LogFS, qui l'an dernier semblait le candidat le mieux placé pour prendre la place du vénérable JFFS2, a perdu un peu de son éclat depuis l'arrivée d'UBIFS. Ce nouveau système est techniquement plus cohérent puisqu'il s'appuie sur une couche (UBI) déjà présente dans le noyau et les tests semblent montrer que ses performances sont meilleures. Le fait que Nokia soit derrière ce système de fichiers alors que LogFS ne peut compter que sur un seul vrai contributeur est également une indication à prendre en compte en ce qui concerne le rythme de développement.
Bien entendu rien n'est encore joué et il faudra surmonter la redoutable épreuve de l'acceptation dans la branche principale avant que nous puissions y voir plus clair dans le domaine des systèmes de fichiers SSD pour Linux.
  • # Bon article

    Posté par (page perso) . Évalué à 10.

    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 =)
    • [^] # Re: Bon article

      Posté par . Évalué à 10.

      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

        Posté par . Évalué à 10.

        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

          Posté par . Évalué à 8.

          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

            Posté par (page perso) . Évalué à 9.

            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

              Posté par . Évalué à 7.

              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

                Posté par . Évalué à 10.

                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

                  Posté par . Évalué à 6.

                  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

                    Posté par . Évalué à 3.

                    '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

                    Posté par (page perso) . Évalué à 10.

                    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 ?
                • [^] # Re: Bon article

                  Posté par . Évalué à 3.

                  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

                    Posté par . Évalué à 10.

                    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

                      Posté par (page perso) . Évalué à 3.

                      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?
              • [^] # Re: Bon article

                Posté par (page perso) . Évalué à 5.

                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.

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                • [^] # Re: Bon article

                  Posté par . Évalué à 3.

                  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

                Posté par (page perso) . Évalué à 2.

                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

          Posté par . Évalué à 7.

          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

            Posté par (page perso) . Évalué à 8.

            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
            • [^] # Re: Vitesse d'écriture

              Posté par . Évalué à 7.

              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

            Posté par . Évalué à 3.

            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

              Posté par . Évalué à 3.

              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)

              "La première sécurité est la liberté"

        • [^] # Re: Bon article

          Posté par . Évalué à 4.



          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

            Posté par . Évalué à 3.

            "les débits sont loin de ceux d'un seul disque."

            Par contre, pour les latences, j'ai très très peur.

            "La première sécurité est la liberté"

            • [^] # Re: Bon article

              Posté par . Évalué à 4.

              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

                Posté par . Évalué à 5.

                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.

                "La première sécurité est la liberté"

                • [^] # Re: Bon article

                  Posté par . Évalué à 6.

                  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

        Posté par (page perso) . Évalué à 1.

        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

          Posté par (page perso) . Évalué à 2.

          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
          • [^] # Re: Bon article

            Posté par . Évalué à 1.

            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.

            "La première sécurité est la liberté"

      • [^] # Re: Bon article

        Posté par . Évalué à 2.

        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

      Posté par . Évalué à 5.

      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
  • # excellent article

    Posté par . Évalué à 10.

    franchement, cette dépêche est un bon candidat à l'article du mois. bon je sais on n'est que le 4 avril ...
    • [^] # Re: excellent article

      Posté par (page perso) . Évalué à 10.

      Il est vrai que cet article est vraiment de très bonne facture. Mes félicitations à son auteur.

      Ben quoi, faut aussi dire quand c'est bien :D

      Alexandre COLLIGNON

      • [^] # Re: excellent article

        Posté par . Évalué à 5.

        Pareil, je m'associe aux félicitations concernant la qualité de l'article.

        Candidat aussi au concours du lien qui permet de passer 15 minutes réellement productive au bureau !
      • [^] # Re: excellent article

        Posté par (page perso) . Évalué à 9.

        Un article de Patrick G. c'est toujours excellent. Souvenez-vous de https://linuxfr.org//2008/01/25/23529.html qui avait recueilli des éloges dithyrambiques !

        Mon petit doigt me dit que Patrick est déjà en train de préparer un article sur le noyau Linux 2.6.25.
        Je me régale d'avance (je triche un peu car j'ai déjà pu voir son texte). ;-)

        Merci Patrick !
    • [^] # Re: excellent article

      Posté par (page perso) . Évalué à 4.

      Je suis d'accord, l'article est vraiment bon. Seul bémol que je mettrais, c'est la tournure de certains liens hypertexte, «sur cette page» est à la limite de «cliquez ici», qui ne met pas en valeur le contenu de la page pointé (notamment pour les bots). Mais bon là je chipote, l'article est vraiment très bon.
    • [^] # Re: excellent article

      Posté par . Évalué à 1.

      En effet, c'est un très bon article. L'auteur est coutumier du fait.

      (rqe : s/vont continuer à être utilisé/vont continuer à être utilisés/)
    • [^] # "Thread Patrick g"

      Posté par . Évalué à 5.

      Faudrait donner un nom à ce thread récurrent, un peu comme les first posts il y a longtemps, mais en pas pareil ...
  • # YAFFS sous Linux

    Posté par . Évalué à 5.

    La GP2X utilise la YAFFS pour son système Linux le firmware est libre , necessite un peu d'amélioration niveau temps de boot , mais sinon je trouve très correcte pour les accès à la carte SD . Ensuite la vitesse d'accès dépend aussi de la carte elle même . (je ne suis pas un fin connaisseur mais je suppose que les cartes estampillé classe 6 , turbo , et 150 X on un accès plus rapide que les autres ... )
    • [^] # Re: YAFFS sous Linux

      Posté par . Évalué à 3.

      il semblerait que la YAFFS et YAFFS2 ne soit pas bien placé simplement à cause de la politique d'Aleph One .. Quand est il au niveau des scans d'en tête et constitution d'index ?
  • # terriblement efficace ?!

    Posté par . Évalué à 7.

    Il est donc bien plus efficace de créer des systèmes de fichiers spécialement dédiés aux disques SSD et dialoguant directement avec la puce de mémoire flash sans passer par le microcontrôleur de wear levelling.

    Hum, en pratique, c'est réalisable ? accéder directement à la flash d'un SSD connecté en SATA ou d'une carte SD connectée en USB ?
    • [^] # Re: terriblement efficace ?!

      Posté par . Évalué à 2.

      après recherche rapide, j'ai trouvé:

      - block2mtd, apparament une émulation de mtd sut block device ... mais ne permettrait pas à priori de passer outre le contrôleur

      - un patch http://marc.info/?t=116731222600007&r=1&w=2 à priori pour les CPU/SoC qui incluent une interface MMC, donc plutôt de l'embarqué.

      Et l'auteur du patch en question dit: "the mtd layer doesn't deal with media larger than 4GB anyway at this point" dans un message d'avril 2007, donc c'est peut-être pas gagné pour les SSD et autres SDHC.
      • [^] # Re: terriblement efficace ?!

        Posté par . Évalué à 4.

        - un patch http://marc.info/?t=116731222600007&r=1&w=2 à priori pour les CPU/SoC qui incluent une interface MMC, donc plutôt de l'embarqué.

        Ca sert à rien vu que l'on passe encore par le controlleur de la sd qui émule la flash comme un disque.

        Et l'auteur du patch en question dit: "the mtd layer doesn't deal with media larger than 4GB anyway at this point"
        Et c'est toujours vrai.
  • # Diagramme

    Posté par (page perso) . Évalué à 8.

    Haaa....mon fabuleux diagramme en ascii art est tout cassé !

    Bon pour ceux qui veulent l'original vous pouvez aller voir le onzième slide de ce document ppt : http://www.linux-mtd.infradead.org/doc/ubi.ppt
    • [^] # Re: Diagramme

      Posté par (page perso) . Évalué à 3.

      Tu devrais mettre tes articles sur ton site personnel avec une jolie présentation et un renvoi sur Linuxfr.
      Tes articles sont denses, informatifs et faciles à lire. Que demander de plus à part une meilleure présentation ?
      • [^] # Re: Diagramme

        Posté par (page perso) . Évalué à 4.

        Quelle serait la valeur ajoutée de les mettre en plus sur mon site perso ?
        • [^] # Re: Diagramme

          Posté par . Évalué à 0.

          Enlarge your p...

          Faire ta pub perso en faite.

          "La première sécurité est la liberté"

        • [^] # Re: Diagramme

          Posté par (page perso) . Évalué à 8.

          L'intérêt serait de
          - rassembler de très bons textes perdus au milieu de tas d'autres
          - avoir un historique en français de l'histoire de l'informatique au 21ème siècle
          - avoir ta photo à côté ;-)
          - te susciter des propositions d'évolution de carrière. Car si j'étais à la recherche de collaborateurs ce serait un argument de poids en ta faveur.
          • [^] # Re: Diagramme

            Posté par (page perso) . Évalué à 9.

            >>> avoir un historique en français de l'histoire de l'informatique au 21ème siècle

            N'exagérons rien ;-)

            >>> avoir ta photo à côté

            Plutôt mourir.
            • [^] # Re: Diagramme

              Posté par (page perso) . Évalué à -1.

              Je ne suis pas certain de la pertinence du lien ci-dessous, mais le camarade google qui sait bien trop de chose sur tout le monde pointe là dessus :

              http://a.wordpress.com/avatar/pvergain-128.jpg
              • [^] # Re: Diagramme

                Posté par (page perso) . Évalué à 5.

                Complètement raté de la part du camarade Google. Je ne sais même pas qui est ce type. En plus ce salopiot à beaucoup de cheveux lui !

                En revanche tu trouvera la réponse dans les commentaires de cette news puisqu'on avait pris des photos lors de la réunion modérorelecteurs : http://linuxfr.org/2007/06/29/22612.html
                • [^] # Re: Diagramme

                  Posté par (page perso) . Évalué à 2.

                  Héhé j'en étais sûr !

                  Le point positif c'est que linuxfr ne pourra pas être tenu responsable de la divulgation d'info privée vu que c'est toi qui donne le lien ;)

                  Du coup, on va pouvoir finir notre vendredi bien pépère au fond de nos sièges.
    • [^] # Re: Diagramme

      Posté par . Évalué à 4.

      Un PPT sous LinuxFR ? La honte !
  • # augmentation du nombre de cycle d'écritures supportés ?

    Posté par (page perso) . Évalué à 6.

    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 ?

      Posté par . Évalué à 2.

      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 ?

        Posté par . Évalué à 10.

        "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.

        "La première sécurité est la liberté"

    • [^] # Re: augmentation du nombre de cycle d'écritures supportés ?

      Posté par . Évalué à 7.

      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.
  • # Quelques questions.

    Posté par . Évalué à 10.

    Déjà bravo pour cet article.

    Alors sinon, quelques trucs que je n'ai pas trop compris : la gestion de l'usure se fait au niveau du contrôleur hardware, dans les SSD, non ? Qu'est-ce que la couche logicielle associée au système de fichiers apporte de plus ?
    (En revanche, je vois très bien ce qu'on peut faire de moins : tous les algos de minimisation du déplacement du bras mécanique.)

    Sinon, quelle différence entre un SSD (super cher : ~500€ pour 32Go), et une clé USB (moins chère : ~150€ pour la même capacité), à part l'interface (or je sais que la conversion SATA/USB ne coûte quasiment rien) ?

    Techniquement, le SSD a un taux de transfert qui peut atteindre environ le triple de celui des meilleures clés USB, mais pourquoi ? (le débit d'USB2 étant pourtant bien supérieur à celui des meilleures clés)
  • # Unités ?

    Posté par (page perso) . Évalué à 1.

    Il manque "juste" les unités dans les résultats des benchs.

    Bien sûr on peut se reporter à la documentation d'iozone pour deviner, mais ce n'est pas très... pro.

    Exemple sans unités:
    J'ai testé avant-hier un vieux disque-dur sur une vieille carte-mère HP (honte à moi, du HP...). Il faisait 4,1
    On est bien avancé sans l'unité qui va avec :-)

    4,1 ms de piste à piste ?
    Non non, 4,1 Mo/s de transfert.
    Poubelle.
    • [^] # Re: Unités ?

      Posté par (page perso) . Évalué à 6.

      Première phrase du paragraphe intitulé " Brief descriptions" :

      The raw numbers are in KByte/sec. The relative numbers denote magnitude of UBIFS relative to another FS.
      • [^] # Re: Unités ?

        Posté par (page perso) . Évalué à 3.

        Je plussoie :-)

        Comment ça j'ai lu trop vite ? Pas du tout, pas du tout. J'ai des preuves. Plein !
  • # Pertinence de cette dépêche ?

    Posté par . Évalué à 5.

    Bonjour,

    Tous ces systèmes de fichiers ne sont-ils pas dédiés dans leur grande majorité aux MTD et par-là même inutilisables sur des block devices tels que les SSD et autres clés USB ?

    Merci d'éclairer ma lanterne,


    AiZ
  • # Complément...

    Posté par . Évalué à 10.

    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.

    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.
    • [^] # Re: Complément...

      Posté par . Évalué à 10.

      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, ...

      J'oubliais : tu parlais d'optimisation des fs classique par rapport à la tête de lecture. Mais là aussi il faut optimiser le fs suivant l'organisation des différentes flash qui compose le disque (oui il y en a rarement qu'une seule).
      Et effet on peut voir ca comme un RAID-0 et pour masquer la latence d'accès à la flash il faut bien repartir les écritures sur les différentes flashs.
    • [^] # Re: Complément...

      Posté par . Évalué à 2.


      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.


      Et ben comme ça ce sera l'occasion de faire le ménage et de virer pour de nécessité de compatibilité avec FAT...
  • # Et à plus long terme ?

    Posté par . Évalué à 4.

    Je n'y connait rien sur le plan technique mais est-ce que ce n'est pas l'organisation complète de nos applications qui devra être revue ?

    Est-ce que l'OS va devoir considérer les "mémoires non volatiles" comme des Swap? Dans ce cas toutes les applications seront lancées une fois pour toutes puis stockées comme des images RAM, directement utilisable (à l'image d'une application Palm).

    Il y a sûrement des obstacles techniques aujourd'hui mais est-ce la direction que suivent les OS à long terme ?
    • [^] # Re: Et à plus long terme ?

      Posté par . Évalué à 1.

      C'est en effet quelque chose de prometteur, surtout avec l'apparition sur le marché de puces MRAM, utilisée actuellement dans certains téléphones portables Motorola, qui leur permet un lancement instantanée de certaines applis même après reboot.
      Malheureusement, la capacité actuelle n'est que de 512ko, mais ça ne peut que s'améliorer :)
    • [^] # Re: Et à plus long terme ?

      Posté par . Évalué à 2.

      Je pense pas, ce qui va devoir etre revu, c'est qu'il faut limiter les accès au disque.
      Ca peut se traduire par :
      - une convervation plus longtemps en cache mémoire avant de flusher les donnée sur le disque
      - désactiver l'option du fs qui stocker le temps du dernier accès
      - monter les fs temporaire en RAM (/tmp, /var/tmp, ...)
    • [^] # Re: Et à plus long terme ?

      Posté par . Évalué à 3.

      >Je n'y connait rien sur le plan technique mais est-ce que ce n'est pas l'organisation complète de nos applications qui devra être revue ?

      Pas avec cette techno:
      - les temps latences pour l'écriture ou la lecture dans une Flash s'ils sont bien inférieurs à ceux d'un disque restent très supérieur à ceux d'une RAM.
      - les temps de latences devraient *augmenter* un peu avec les Flash MLC qui fournissent des capacités supérieures, pas baisser.

      Je ne connais pas les chiffres exacts, mais je dirais au pif environ 10^-4s pour la Flash contre 10^-7s pour la RAM, un facteur mille ce n'est pas rien..

      Donc je pense que l'organisation actuelle de nos application va rester..
  • # 140 years @ 50GB write per day

    Posté par . Évalué à 4.

    Est-ce que les algos pour minimiser l'impact de l'écriture sur SSD est nécessaire alors que certain produit propose une endurance de 50Go d'écriture séquentiel par jour pendant 140 an ?

    http://www.mtron.net/English/Product/ProductDetail.asp?itemc(...)
    • [^] # Re: 140 years @ 50GB write per day

      Posté par . Évalué à 10.

      Oui enfin les données constructeurs on sait tous ce que ça vaut.
      Quand on t'annonce 140 ans @ 50 Go par jour alors que plus bas tu as un MTBF de 1 million d'heure (soit environ 114 ans) tu peux déjà te poser des questions.
      Ensuite tu vois la présence des données qui n'est "garantie" que pour 10 ans et après que le produit n'est garantie que 3 ans...
    • [^] # Re: 140 years @ 50GB write per day

      Posté par . Évalué à 6.

      Oui mais c'est du théorique où tu écris uniformément dans toute la flash, ou tout les "secteurs" de la flash sont de bonne qualité, à chaque écriture du remplit complètement l'unité d'écriture de la flash.

      En effet avec 10^6 cycles d'écriture possible, sur un disque de 2Go, ça donne 2*10^6Go au total, soit pour une écriture journalière de 50Go, plus de (2*10^6Go/50Go ~ 140*265 ) jours, soit 140 ans.
      • [^] # Re: 140 years @ 50GB write per day

        Posté par . Évalué à 10.

        C'est sûr qu'en passant les années à 265 jours on fait durer le disque plus longtemps. Le reste du temps on le laisse en jachère ?
  • # Un raz de marée ? J'achète !

    Posté par . Évalué à 3.

    Ouais j'achète.

    Mais y a pas grand chose de vendu au grand public, où je me trompe ?
    Sur les sites de vente français, sorti des Transcend (débits plutôt limites, si j'ai bien suivi), il reste quoi ? Un Samsung par-ci (zut, uniquement SATA ! Et pour maintenir mon vieux portable resté en bon vieux "PATA"?), un super talent par là (ah, ben non, pas en France)

    Pourtant, y a des super trucs, je ne citerai en plus de Intel que Pny (http://www2.pny.com/MarketingPromotions/SolidStateDrives/2_5(...) ), mais... pas distribué, en tout cas ne m'est pas accessible.

    Al., qui les a un peu là
    • [^] # Re: Un raz de marée ? J'achète !

      Posté par . Évalué à 2.

      >Un Samsung par-ci (zut, uniquement SATA ! Et pour maintenir mon vieux portable resté en bon vieux "PATA"?)

      Il y a des adaptateurs SATA/PATA.

      Et en effet il y a peu de modèle vendu au grand public, mais c'est normal il y a encore très peu de constructeurs et de modèles. D'ici un an ça devrait être viable.
  • # Serveur faible énergie ?

    Posté par . Évalué à 3.

    Selon le gain au plan énergétique, je me demande si en couplant ça à un micro genre ARM, on pourrait pas faire des petits serveurs très légers.

    Quelque chose qui permettre de faire un peu de FTP, héberger des sites web (php, sql), quelques comptes mail, décentraliser, quoi, mais sans que chacun doive laisser un PC entier tourner perpétuellement chez lui. Le problème énergétique doit être un frein à l'autohébergement pour pas mal d'entre nous.

    Cela dit ça existe peut-être déjà des petites architectures qui consomment peu. Mais là je pense à un truc sans écran, pilotable via un acces distant (un autre PC du réseau). Vraiment réduit.

    (Et cela dit à quoi bon réduire la conso d'un serveur s'il est relié à une freebox/radiateur ?)
    • [^] # Re: Serveur faible énergie ?

      Posté par (page perso) . Évalué à 5.

      Un truc comme soekris ?

      http://www.soekris.com/
      • [^] # Re: Serveur faible énergie ?

        Posté par . Évalué à 1.

        Ah ben oui par exemple.

        Il faudrait voir comment ça se comporte niveau conso et perfs. Mais ça semble répondre précisément au "besoin" dont je parlais.
      • [^] # Re: Serveur faible énergie ?

        Posté par . Évalué à 3.

        De l'info ici aussi : http://wiki.soekris.info/
    • [^] # Re: Serveur faible énergie ?

      Posté par (page perso) . Évalué à 4.

      Sinon y a aussi le FIT PC http://www.fit-pc.com/ . 5W, 2 RJ45, c'est devenu ma passerelle internet notamment.
      • [^] # Re: Serveur faible énergie ?

        Posté par . Évalué à 2.

        Ouah, 5W ça fait vraiment pas beaucoup. Le net5501 de Soekris a une alim dimensionnée à 20W max. Pourtant, pour revenir au sujet, le FIT PC a un disque dur mécanique (2.5” IDE 60GB).

        Le prix des deux est comparable. Soekris en boîte 250 €, FAT PC $300.
        • [^] # Re: Serveur faible énergie ?

          Posté par (page perso) . Évalué à 3.

          Attention, tu confonds consomation du produit et puissance maximale fournit par l'alim.

          Dire que l'alim d'une soekris est de 20W veux dire que si la machine consome plus de 20W, ca marchera plus. Ca veux pas dire que ca consomme 20W en continue.

          A mon avis, le FIT PC et la soekris consomment autant l'un que l'autre : en effet, c'est exactement les mêmes composants énergivore : un Geode à 500MHz (pour la soekris 5501-70).

          Pour info, ma via PD6000E à 600MHz avec une alim 60W, carte wifi ralink et disque dur 3.5 160Go consomme 20W (de tête, mesuré avec un wattmètre).

          Perso, le fic pc m'a l'air très interessant, mais il lui manque la possibilité de faire point d'accès wifi, ce que permet la soekris, mais la soekris n'a ni le port vga, ni la sortie audio.
          • [^] # Re: Serveur faible énergie ?

            Posté par . Évalué à 2.

            Je ne confonds pas max et nominal mais je n'avais pas imaginé que le max puisse être x4 du nominal. Je n'ai en fait aucune idée d'un rapport normal entre les deux. Donc je ferais mieux de me taire.

            Si c'est pour faire un server, le VGA et la sortie audio m'importent peu. Mais le wifi aussi, en fait.

            Une chose à laquelle je n'ai pas pensé, en terme de perf, c'est l'upload. En ADSL, c'est peut-être limitant. Evidemment ça dépend de la charge du serveur.

            RIen à voir, mais les boîtes des soekris sont super jolies. Les fit pc sont pas mal non plus, mais moins chouettes à mon avis.

            Je devrais mesurer la conso de mon PC, elle est peut-être beaucoup plus faible que je ne l'imagine. Cela dit les boîtiers dont on parle ont aussi l'avantage de ne pas faire de bruit.
            • [^] # Re: Serveur faible énergie ?

              Posté par (page perso) . Évalué à 3.

              Je n'ai en fait aucune idée d'un rapport normal entre les deux.

              Il n'y a en général pas plus que nominal < max.

              Si c'est pour faire un server, le VGA et la sortie audio m'importent peu. Mais le wifi aussi, en fait.

              En fait, l'utilité que j'en ai personnellement, c'est un serveur routeur. Comme dans serveur, il y a serveur mpd, la sortie audio est importante. Le VGA ne l'est pas, c'est juste une facilité. Mais bon, chacun a ses besoins spécifique ;-)

              Une chose à laquelle je n'ai pas pensé, en terme de perf, c'est l'upload. En ADSL, c'est peut-être limitant.

              Il me semble qu'une soekris 4800 est suffisante pour chiffrer le débit de l'upload ADSL, donc pas de problèmes avec les geodes à 500MHz. Sur http://www.kd85.com/ y'a le bench de ssl.

              Je devrais mesurer la conso de mon PC, elle est peut-être beaucoup plus faible que je ne l'imagine.

              Mon sempron 2800 avec une carte nvidia intégré (d'il y a 3-4 ans) et un écran TFT 15" consomment en tout 120W (dont 15W du moniteur je pense). Je crois que l'alim est une 200W (barebone).
              • [^] # Re: Serveur faible énergie ?

                Posté par . Évalué à 4.

                Il n'y a en général pas plus que nominal < max.

                Je ne comprends pas. Tu veux dire qu'il n'y a pas de généralité ? Qu'on a toujours max > nom mais qu'il n'existe pas de N tel qu'on ait toujours en général et par sécurité max > N x nom ?

                Il me semble qu'une soekris 4800 est suffisante pour chiffrer le débit de l'upload ADSL

                Je voulais dire que pour installer un serveur chez soi il ne suffit pas que la machine tienne la charge, il faut aussi avoir une connexion perso suffisante en UL pour que ça rame pas trop du point de vue de l'utilisateur.

                Mon sempron 2800 avec une carte nvidia intégré (d'il y a 3-4 ans) et un écran TFT 15" consomment en tout 120W

                Ca fait déjà pas mal plus. En admettant qu'on n'utilise pas d'écran on est quand même dans un ordre de grandeur de 100 Watts. Soit vingt fois plus.
                • [^] # Re: Serveur faible énergie ?

                  Posté par (page perso) . Évalué à 4.

                  Je ne comprends pas. Tu veux dire qu'il n'y a pas de généralité ? Qu'on a toujours max > nom mais qu'il n'existe pas de N tel qu'on ait toujours en général et par sécurité max > N x nom ?

                  Oui, c'est ce que je veux dire. En fait, en conception, il faut que les pics de consomations soient inférieurs au max, et c'est tout. En pratique, je n'ai constaté aucun lien, d'autant plus que, souvent, les alims prennent une marge de sécu en proportion avec l'évolutivité du produit (possibilité d'ajouter des composant energievore).

                  Je voulais dire que pour installer un serveur chez soi il ne suffit pas que la machine tienne la charge, il faut aussi avoir une connexion perso suffisante en UL pour que ça rame pas trop du point de vue de l'utilisateur.

                  OK, OTAN pour moi.

                  Soit vingt fois plus.

                  Oui, d'ou l'interret de ces petites boites pour du serveur.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.