Journal Unified Flash File System

Posté par (page perso) .
Tags : aucun
14
24
mai
2009
Le projet UFFS, pour Unified Flash File System est un système de fichiers ayant pour but de supporter tous les périphériques à base de mémoire flash comme les clefs USB, les disques durs SSD, les cartes mémoires (SDCard, MMC...); de plus, il sera disponible, dans sa version finale, sur les systèmes d'exploitation principaux (GNU/Linux, Microsoft Windows, MacOSX).

La première version est attendue courant Juin 2009. Dans un premier temps, le système de fichiers ne fonctionnera qu'en lecture seule. Ceci aura pour objectif d'ouvrir le projet au public afin d'obtenir les premiers retours, ainsi que de permettre de possibles contributions.

Toutes les informations sont sur le site officiel http://uffs.org/. Par ailleurs, nous essayerons de tenir à jour ce journal afin de vous tenir au courant des avancées du projet.
  • # Je ris, mais c'est sûrement pas drôle.

    Posté par . Évalué à 9.

    Dans un premier temps, le système de fichiers ne fonctionnera qu'en lecture seule

    ça veut dire qu'on va pouvoir lire un système de fichier, mais pas écrire dessus. On va donc pas avoir grand chose à y lire...
    • [^] # Re: Je ris, mais c'est sûrement pas drôle.

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

      Oui .. en effet, sauf que ... On se base sur le format on-flash de UBIFS (et pas forcément avec UBI en dessous, mais la conversion est triviale avec EBM).
      Donc, il y'aura de quoi lire.

      En fait, pour faire un peu plus technique, uffs c'est:
      - Un port de UBIFS en userspace sous linux, avec fuse
      - Un port de UBIFS en userspace sous windows avec dokan
      - Un futur port sous WinCE (kernelspace)
      - Un futur port sous Windows (kernelspace)

      L'intérêt ? UBIFS est fait pour être conscient des caractéristiques de la mémoire flash: taille minimale d'IO, taille d'un erase block, limitation des écritures/effacements, wear leveling (via UBI en fait).

      Du coups, on fait une couche plus générique qu'UBI, qui peut gérer aussi les périphériques (sans wear leveling, ou avec, au choix). Mais on conserve les bonnes pratiques imposées par UBIFS (pas d'écritures plus petites que la taille d'io minimale, on essait d'écrire erase block par erase block).

      Voila, pour plus de détails, allez faire un tour sur le site web !
      • [^] # Re: Je ris, mais c'est sûrement pas drôle.

        Posté par . Évalué à 7.

        L'intérêt ? UBIFS est fait pour être conscient des caractéristiques de la mémoire flash: taille minimale d'IO, taille d'un erase block, limitation des écritures/effacements, wear leveling (via UBI en fait).

        Sauf que pour les clefs USB, les disques durs SSD, les cartes mémoires (SDCard, MMC...), tu n'as pas acces directement a ces caractérisques.
        Tout est masqué par la FLT présente dans le controlleur.

        Comment tu vas choisir ta taille d'erase block ?
        Comment tu connais la taille io minimale ?
        Comment tu peux garantir un résultat correct sans connaître vraiment ce que fait la FTL derrière ton dos.
        Certaines FTL/matos sont vraiment foireuse et corrompe tes données de manières invisible.

        Pour moi sur ses périphériques il faudrait plutôt mettre un fs qui est robuste aux corruptions aléatoires du support.


        PS : http://www.linux-mtd.infradead.org/doc/ubifs.html#L_raw_vs_f(...)
        • [^] # Re: Je ris, mais c'est sûrement pas drôle.

          Posté par . Évalué à 4.

          A et puis j'oubliais, certaines FTL sont optimisé pour FAT...
        • [^] # Re: Je ris, mais c'est sûrement pas drôle.

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

          Comment tu vas choisir ta taille d'erase block ?

          C'est quand même vachement souvent 128K.

          Comment tu connais la taille io minimale ?

          Entre 512 et 4K, la majorité c'est 2K. Sur un SSD/Clef USB/.. c'est normalement la taille d'un secteur. Ou au moins, la taille d'un secteur est une valeur qui sera bonne.

          Comment tu peux garantir un résultat correct sans connaître vraiment ce que fait la FTL derrière ton dos.

          En gros, http://tytso.livejournal.com/60368.html

          Certaines FTL/matos sont vraiment foireuse et corrompe tes données de manières invisible.

          UBIFS est plein de crc de partout, ça permet déjà de détecter ces corruptions aléatoires.
          • [^] # Re: Je ris, mais c'est sûrement pas drôle.

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

            Entre 512 et 4K, la majorité c'est 2K. Sur un SSD/Clef USB/.. c'est normalement la taille d'un secteur. Ou au moins, la taille d'un secteur est une valeur qui sera bonne.

            Il me semble que la plupart des SSD remontent des valeurs débiles du genre 512 octets/secteur pour garder une vague compatibilité avec les disques durs... donc la valeur ne sera pas super adaptée au SSD...

            Comment tu peux garantir un résultat correct sans connaître vraiment ce que fait la FTL derrière ton dos.

            Tu peux faire des hypothèses et tirer des conclusions de certains tests, jusqu'à la prochaine révision de la FTL qui t'obligera à tout refaire. Ou pire, les déductions ne seront valables que pour ce SSD-ci et pas celui d'un autre fabricant :(...

            Certaines FTL/matos sont vraiment foireuse et corrompe tes données de manières invisible.

            Certains fabricants de Flash "inventent" des trucs (genre http://download.micron.com/pdf/technotes/nand/tn2941_idm_cop(...) ) pour essayer d'éviter ça...
          • [^] # Re: Je ris, mais c'est sûrement pas drôle.

            Posté par . Évalué à 4.

            Holala, je n'ai pas de document "sérieux" à te fournir, mais c'est justement le manque de documents sur tous les périphériques de type bloc (Clés USB, carte SD, disque SSD) et puis pleins d'articles que j'ai lu qui me font dire que ça ne sert absolument à rien de vouloir contrer ce que fait la FTL. UBI et consort sont faits pour des périphériques MTD, et c'est tout.

            Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.

            Ensuite, tu n'as aucun contrôle sur comment est géré le cache, l'écriture, etc. de tes blocs derrière, à moins de tripatouiller dans le système de gestion de périphs bloc du kernel.

            Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.

            Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ? Peut-être qu'elle flush tout à chaque écriture d'un bloc (= effacement d'un erase block qqpart, récriture du contenu en entier + tes nouvelles données .... super efficace ; je soupçonne les clés USB de faire ça, vu leur durée de vie), ou alors peut-être est-elle plus "intelligente", mais comment va se comporter ton algo avec ça ?

            Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.

            Voilà, tout ça sans parler du "problème", si votre objectif est de faire quelque chose qui marche partout (vu que vous faites du windows aussi, je suppose que c'est un peu votre objectif) d'arriver à avoir un format assez répandu pour être lu de manière pratique sur beaucoup de machines ...
            • [^] # Re: Je ris, mais c'est sûrement pas drôle.

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

              Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc !

              Non. Un périphérique bloc peut avoir des blocs de taille différente.

              J'ai vu une clef USB avec des blocs de 2 ko, qui fonctionnait à merveille sous Linux, qu'on pouvait partitionner avec Parted et tout. Comme c'était une clef de promotion Microsoft, je pense qu'elle devait être bien prise en charge également sous Windows.

              Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.

              Tel que je vois les choses, un SSD, une clef USB ou n'importe quel medium de stockage par blocs devrait exposer une taille de bloc optimale pour son travail. Si ma clef USB expose des blocs de 512 octets, et que ses eraseblocs font 4 ko, c'est le problème de son fabricant qui est un tocard, et ce n'est certainement par le du système de fichiers, de la couche d'accès blocs ou du système d'exploitation. Donc pas au système de se préoccuper de ça : utilisons les blocs fournis par les périphériques.
              • [^] # Re: Je ris, mais c'est sûrement pas drôle.

                Posté par . Évalué à 4.

                Je pense que ce que tu décris, c'est la taille d'un secteur, qui n'est pas la même chose qu'un bloc : effectivement, des périphériques indiquent des tailles de secteur différents de 512 octets, mais les blocs gardent cette taille. À vérifier quand même, mais là il est tard ...
            • [^] # Re: Je ris, mais c'est sûrement pas drôle.

              Posté par . Évalué à 2.

              Tout le système des block io de linux et des autres OS est basé sur cette assomption.

              Tout système de block Io de Linux montera au ciel... et je viens de comprendre que le Paradis est en orbite autour de Jupiter! \o/
            • [^] # Re: Je ris, mais c'est sûrement pas drôle.

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

              Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.

              Oui, mais ce n'est pas vraiment adapté aux SSD (qui ont généralement des pages de 2K ou plus)... C'est pour ça que j'ai dit "vaguement compatible", car ils ont choisi de les montrer comme des périphériques de type bloc car certains OS ne connaissent pas autre chose et comme ça, la diffusion des SSD se fait mieux, même si ça oblige à avoir des FTL qui font des trucs de psychopathes derrière ton dos.

              Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.

              Il y en a beaucoup, mais ça reste dénombrable : 512 pour les petites capacités, puis 2k, 4k ou 16k selon le type de Flash (MLC ou SLC), la capacité et le fabricant (comment ça c'est le bordel ?). Mais c'est vrai qu'avec l'interface bloc il n'y a aucun moyen de remonter des infos comme ça ("youhou, j'utilise des pages de 2k et des erase blocks de 128k"), et je suis pas sûr que ça va mieux marcher si on fait des suppositions hasardeuses ("bon allez, on considère qu'ils ont tous des pages de 4k")...

              D'un autre côté, si on pousse un peu le raisonnement, on s'en fout un peu : considérer les SSD d'après les caractéristiques de la mémoire Flash utilisée est une simplification un peu rapide et risquée, étant donné que tout passe par la FTL, qui est fermée, non documentée, et qui fait ce que bon lui semble (rien que les premières générations de SSD qui ont des perfs immondes lors d'IO en parallèle alors qu'ils sont composés de plusieurs puces Flash, donc en théorie plusieurs accès concurrents possibles...).

              Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ?
              Je ne veux pas prendre leur défense, mais sur le coup, _personne_ ne sait ce que font les FTL (bon, ok, les gens qui les codent, et c'est tout). On peut avoir plusieurs indications en lisant les brevets déposés (beurk, indigestes) ou les quelques articles ou papiers qui parlent des FTL (BAST, FAST, STAFF, DFTL, SuperBlock...), mais une nouvelle fois, rien n'indique qu'ils sont implantés...
              • [^] # Re: Je ris, mais c'est sûrement pas drôle.

                Posté par . Évalué à 3.

                Bon, qu'il n'y ait pas de mécompréhension : je suis complètement d'accord que ce système de bloc ne soit pas du tout adapté aux mémoires Flash (que ce soit SSD ou USB/SD), mais là je suis passé en mode "pragmatique" car aujourd'hui, aucun constructeur ne fait l'effort d'y remédier par un moyen -- même pas idéal -- un tant soit peu "pas mauvais". Tout le monde utilise un FTL, point. Les seuls qui ont un accès direct à la Flash, c'est dans l'embarqué, et encore, juste pour la Flash "de base" (par exemple, il me semble que dans l'iPhone/iPod Touch, le firmware est en accès MTD, mais le stockage de 8/16/32Go est en oneNand, soit le protocole SD, qui marche aussi par bloc de 512). Bref, rien a destination du grand public.

                Ensuite, ce coté bloc de 512, quand je disais que c'était inhérant au système de bloc, ce n'est pas que ça, c'est aussi inhérant à la norme ATA ! (et donc SATA) Bref, ce n'est pas qu'un problème de soft, c'est aussi un problème de hard (enfin, moitié/moitié puisque la stack ATA c'est un bout de driver et un bout de hard). Donc ce n'est pas près, selon moi, de changer.

                Comme personne n'a poussé pour un système de connexion spécifique aux mémoires Flash (on aurait peut-être pu faire quelque chose "au dessus" du protocole physique SATA, voire encore plus crade mais plus "facile", au dessus des commandes ATA ?) et bien tout le monde fait des FTL. Et effectivement, personne ne sait ce qu'il fait, garder des secrets ça arrange bien les industriels.

                Enfin bref, pour les histoires de capacités, c'est peut-être facile aujourd'hui, mais j'ai entendu que pour simplifier le design des puces de grosses capacités, ils voulaient faire des erase block dont la taille se compte en Mb, ce qui ne va pas arranger les choses. D'ailleurs c'est peut-être déjà le cas, mais on n'en sait rien. Encore du secret.

                Pour conclure, oui ce serait bien d'arriver à faire un truc adapté (et libre, en plus) mais je ne pense pas que ce soit faisable vu le comportement des industriels aujourd'hui.
                • [^] # Re: Je ris, mais c'est sûrement pas drôle.

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


                  Ensuite, ce coté bloc de 512, quand je disais que c'était inhérant au système de bloc, ce n'est pas que ça, c'est aussi inhérant à la norme ATA ! (et donc SATA) Bref, ce n'est pas qu'un problème de soft, c'est aussi un problème de hard (enfin, moitié/moitié puisque la stack ATA c'est un bout de driver et un bout de hard). Donc ce n'est pas près, selon moi, de changer.


                  Et bah ... justement si. D'une part la transition vers des secteurs de 4K est en cours.
                  D'autre part, des commandes ATA spécifiques aux SSD apparaissent (voir TRIM/Discard)
                  Toutes ces infos, on les trouve sur lwn.net, ou dans le blog de Ted T'so cité précédemment.
                  • [^] # Re: Je ris, mais c'est sûrement pas drôle.

                    Posté par . Évalué à 2.

                    D'une part la transition vers des secteurs de 4K est en cours.
                    Oui, c'est plus pratique aujourd'hui pour s'aligner à la taille des pages en RAM, et s'adapter plus facilement aux FS, et pour les grandes tailles de disque. Mais ça ne change rien pour les SSD qui ont des tailles de page différentes. À moins qu'il y ait un effort d'unification à 4ko ? Mais je n'en ai jamais entendu parler. Et puis ça ne règle pas le problème de la taille des erase-block, ni même des "zones" si on passe par une FTL bas de gamme.

                    des commandes ATA spécifiques aux SSD apparaissent (voir TRIM/Discard)
                    Oui enfin encore une fois, c'est une adaptation aux FTL, pour qu'elles soient utilisées un peu mieux (enfin, pour qu'elles ne soient pas complètement nazes ... ce qui est mieux que rien, mais pas top). Et ça existait déjà dans les specs CompactFlash (en mode ATA), même si à priori ça n'a jamais été implémenté par personne ... Et puis surtout ça devient assez drôle au niveau des implications que ça a par rapport aux utilisations un peu inhabituelles comme l'accès direct (sans passer par le FS) ou la récupération de données, cf http://marc.info/?l=linux-ide&m=123266840917245&w=2 et suivants, j'ai le flemme d'expliquer pour l'instant.

                    Bref, ça n'améliore qu'un peu la situation, et surtout, c'est fait dans l'esprit de garder absolument les FTL, pas d'imaginer de travailler sans.
  • # Disque dur SSD

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

    Non, pas disque dur, justement ! Lecteur, périphérique, tout ce que vous voulez, mais pas disque dur. :-)

    D'ailleurs, le mot « drive » est déjà présent dans le sigle SSD, donc parler de lecteur SSD, c'est comme parler de disque CD…
    • [^] # Re: Disque dur SSD

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

      Merci pour cette remarque. C'est vrai qu'on a souvent employé ce terme lors de précédentes présentations pour rendre le discours un peu plus accessible à certaines personnes, notamment celles qui connaissent uniquement le terme "disque dur".

      On veillera à corriger cette erreur à l'avenir.

      Merci.
      • [^] # Re: Disque dur SSD

        Posté par . Évalué à 3.

        Et ce ne sera pas facile vu que la solution technique (disque dur) a remplacé la fonction (mémoire de masse).
  • # UID optionnels ou mapping d'UID ?

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

    Pas mal de media Flash sont amovibles, donc vous allez être confrontés à un problème courant : un ami m'a passé une clef USB, mais il est 1001 alors que je suis 1000, donc je ne peux pas modifier les fichiers.

    En clair : les permissions Unix, c'est cool… sauf sur les périphériques qui servent pour échanger des documents, où c'est franchement nuisible.

    Donc, s'il vous plaît, dans ce système de fichiers du futur, pourriez-vous, au choix :
    - rendre optionnelle la prise en charge des UID, et en faire une option du système de fichiers ;
    - proposer un mécanisme de mapping d'UID, en option de montage ?
    • [^] # Re: UID optionnels ou mapping d'UID ?

      Posté par . Évalué à 3.

      alors là je ne peux que confirmer, j'ai eu plusieurs fois ce problème en utilisant un disque dur ( externe en usb 2.0 ) pour transferer des données entre plusieurs pc
      • [^] # Re: UID optionnels ou mapping d'UID ?

        Posté par . Évalué à 2.

        donc vive FAT!
        • [^] # Re: UID optionnels ou mapping d'UID ?

          Posté par . Évalué à 1.

          Sauf pour les fichiers de plus de 2 Go ...

          Bon, OK, même windows sait recoller des fichiers en ligne de commande ...
        • [^] # Re: UID optionnels ou mapping d'UID ?

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

          J'ai constaté avoir plus de corruptions de fichiers sur mes cartes SD/CF/Clés USB avec ext2/3/reiserfs qu'en FAT32... Du coup j'en suis à me demander si mettre mon / en FAT32 serait pas une bonne idée (mon OS est sur une CF ou un SSD).

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

          • [^] # Re: UID optionnels ou mapping d'UID ?

            Posté par . Évalué à 4.

            Attention à certains programmes qui refusent de se lancer quand les permissions de leurs fichiers ne sont pas assez restrictives (et qui sont impossibles à mettre avec FAT32, ou alors avec des bidouilles par dessus) : ssh, sudo, etc.
    • [^] # Re: UID optionnels ou mapping d'UID ?

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

      En attendant ... ntfs-3g permet de faire ce genre de choses, et de gérer les fichiers de plus de 2Go ... Mais bon, c'est ntfs ...

      Par contre, à mon avis, il suffirait de patcher le vfs pour avoir cette fonctionnalité dans tout les FS.
  • # Sur les systèmes d'exploitation principaux...

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

    Il semblerait qu'avec FUSE ça puisse aussi tourner sous les autres systèmes d'exploitation principaux que sont les *BSD.
  • # Et le fonctionnel ...

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

    J'imagine déjà un ordinateur :
    Une partition sur un SSD pour le système (2 Go). Très rapide en temps d'accès et en lecture.
    Une partition sur un SSD pour les applications (14 Go). Rapide en temps d'accès et en lecture.
    Une partition sur disque dur pour les données.

    Votre système de fichiers semble prendre en compte les spécificités matérielles.
    Peut il prendre en compte les spécificités fonctionnelles ?
    La taille d'une partition (2 Go ou 16 Go) sur SSD fait-elle varier le temps d'accès et la vitesse de lecture sur la partition ?
    Y a-t-il des optimisations possibles à attendre dans ce sens ?
    • [^] # Re: Et le fonctionnel ...

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

      Le projet à moins de six moins, et on est encore loin de faire des bench. Mais théoriquement, c'est censé être scalable, donc la taille ne devrais pas trop faire varier les performances. J'aurais des résultats plus concrets en septembre.
      • [^] # Re: Et le fonctionnel ...

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

        On peut très bien imaginer des cartes mères avec une mémoire flash de 2 Go pour le système et une mémoire flash de 16 Go pour les applications 'principales'.

        Outre les performances mécaniques des puces, il faudra un système de fichier pour optimiser le fonctionnement de l'ensemble.
        La diffusion de masse de votre travail passera, à mon avis, par un plus au niveau des performances et de la fiabilité...
        Quitte à sortir des standards et modèles actuels.

        Je ne crois pas à la généralisation d'un système de fichier 'universel' pour les mémoires flash.
        Ou alors, ça viendra d'une grosse structure en libre ou pas libre (Vous avez prévu de faire racheter votre travail ???)
        • [^] # Re: Et le fonctionnel ...

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

          De mon point de vue, si il y'avais de telles cartes, il ne faudrais pas les gérer à la main. Il faudrais plutôt s'en servir comme une sorte de cache, un peu comme ReadyBoost.

          Je sais pas si il existe déjà quelque chose qui va dans ce sens sous Linux.
          • [^] # Re: Et le fonctionnel ...

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

            Je sais pas si il existe déjà quelque chose qui va dans ce sens sous Linux.

            Sous Linux, non, mais sous Unix, oui, depuis le début. Il me semble que /bin et /usr/bin sont distincts pour pouvoir mettre /bin (qui sert plus souvent) sur un tambour magnétique plus rapide que le reste.
          • [^] # Re: Et le fonctionnel ...

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

            Le coût et la taille des mémoires flash permettent aujourd'hui d'avoir tout le système dessus et toutes les apllications.
            Pour 10 euros, tu as une clé USB de 8Go aujourd'hui, probablement 16 Go dans un an.
            ReadyBoost n'est qu'un cache car le système est tellement lourd qu'il ne tient pas sur une mémoire flash... ou celle ci est hors de prix.
            Si j'ai un SSD et un disque dur sur mon ordi, je fais un / pour le SSD et un /home sur le disque dur, pas de soucis.
            Les puces mémoires dont je parle remplacent le SSD.
            Il n'y aurait pas de 'nappe' mais un bus de communication, donc plus rapide au niveau matériel.
            Mais pour ça, il faut le système de fichier qui optimise tout ça. Surtout en lecture.

            De même qu'il ne sert à rien de faire des SSDs de 100 Go pour les particuliers.
            Trop cher pour le gain à l'utilisation.
            • [^] # Re: Et le fonctionnel ...

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

              Je ne me fierais pas aux clefs usb actuelle pour avoir un système fiable au vu de leur faible taux de lecture/écriture. Donc ça ne m'étonnerais pas qu'un système à 8Go fiable soit beaucoup plus cher.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

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