Journal Ext4 va sortir !!!

Posté par  .
Étiquettes : aucune
18
18
oct.
2008
Le depuis longtemps attendu ext4 était jusqu'à maintenant nommé "ext4dev" dans le noyau. Maintenant ça sera "ext4" (2.6.28).
Que dire de ext4 ? Ben qu'il est plus mieux bien qu'ext3.

Et après ext4 ? ext5 ?
Il semble que non. Ça sera btrfs probablement.
L'excellentissime Theodore Ts'o donne son avis :
http://thread.gmane.org/gmane.linux.file-systems/26246/focus(...)
As far as btrfs is concerned, one of the things that you may not know
is that about a year ago (on November 12-13, 2007), a small group key
filesystem developers, that included engineers employed by HP, Oracle,
IBM, Intel, HP, and Red Hat, and whose experience included working
with a large number of filesystems: ext2, ext4, ext4, ocfs2, lustre,
btrfs, advfs, reiserfs, and xfs came together for a two day "next
generation filesystem" (NGFS) workshop. At the end of the that
workshop, there was unaminous agreement (including from yours truly)
that (a) Linux needed a next generation filesystem to be competitive,
(b) Chris Mason's btrfs (with some changes/enhancements discussed
during the workshop) was the best long-term solution for NGFS, and (c)
because creating a new enterprise filesystem always takes longer than
people expect, and even then, it takes a while for enterprise users to
trust a new filesystem for their most critical data, ext4 in the next
generation of filesystems was needed as the bridge to the NGFS.

[...]

Given btrfs's current status, in terms of its functionality, even its
format is not fully cast into stone yet, and given Chris's reputation
and skills as a kernel devleoper, my personal opinion is that we would
not be making a "special case exception" for btrfs to get it into
mainline, but rather something which makes completely good sense.


Quand beaucoup d'expert de systèmes de fichier sont d'accord...
C'est un développeur, et non des moindres, d'ext[34] qui le dit.

Vu ici : http://www.heise-online.co.uk/news/Kernel-Log-Ext4-completes(...)
et ici : http://www.osnews.com/story/20409/Ext4_Completes_Development(...)

  • # Presque bien

    Posté par  . Évalué à 1.

    C'est un journal qui aurait été parfait avec au moins un lien avec les explicatiions sur les avancées de btrfs, un truc complet et pédagogique comme aurait pu écrire patrick_g.

    Par exemple un lien vers ceci:
    http://linuxfr.org/2008/01/24/23607.html

    • [^] # Re: Presque bien

      Posté par  . Évalué à 4.

      Ou une traduction en fraçais pour les incompétents comme moi ....ou simplement pour rendre le tout plus agréable à lire.

      • [^] # Re: Presque bien

        Posté par  . Évalué à 10.

        Pour faire court.
        Les développeurs de système de fichier de Linux (de tous bords) pensent qu'il faut une nouveau système de fichier pour que Linux reste dans la course. Pas un nouveau qui est dans la continué de l'existant, mais un nouveau qui serait d'une autre génération. C'est la conclusion d'une rencontre entre développeurs de novembre 2007.
        Pour Theodore Ts'o, btrfs est ce nouveau système de fichier. Il n'avance pas d'arguements techniques mais fait remarquer :
        - le développeur principal de btrfs a du temps pour développeur btrfs et est très respecté.
        - btrfs n'est pas la création d'une seule personne, mais une création d'experts en système de fichier. Ceci va dans la droite ligne de Theodore Ts'o qui pense que ce qui fait une bon système de fichier c'est aussi, et surtout, la quantité de compétences qu'il y a autour.

        Theodore Ts'o ne veut pas que btrfs soit inclus à Linux via une exception, mais car btrfs fait (presque) l'unanimité en tant que système de fichier de la prochaine génération. Btrfs sera peut-être dans Linux 2.6.29.

        Ainsi il pense que ext4 est un pont (nécessaire) vers btrfs.Btrfs ne sera pas prêt pour les entreprises avant de nombres mois voire années.

    • [^] # Re: Presque bien

      Posté par  . Évalué à 10.

      Je ne voulais pas faire de l'ombre à patrick_g.

      > les explicatiions sur les avancées

      Tu peux avoir une floppée d'explications et d'arguments. Les systèmes de fichier sont terriblement complexes et avec des contraintes inouïes.
      Depuis des années on explique avec arguments à l'appuis que ext3 est pourri et dépassé. Toujours avec des arguments, on dit qu'il faut utiliser ReiserFS ou XFS ou [autre].
      Bref, toutes ses fausses vérités me fatigue et je préfère prendre l'avis d'experts reconnus au-lieu de me farcir un argumentaire (forcément biaisé) que je comprend à moitier. Oui, c'est minable.

      • [^] # Re: Presque bien

        Posté par  . Évalué à 10.

        Non c'est sage, et humble.

        • [^] # Re: Presque bien

          Posté par  . Évalué à 1.

          Non, c'est tout ça en même temps : c'est ça qu'est beau !

      • [^] # Re: Presque bien

        Posté par  . Évalué à 1.

        Je ne t'ai pas suggéré d'avoir mis les explicatiions sur les avancées, mais un lien vers les explicatiions sur les avancées.

        En effet après avoir lu ton journal, fort intéressant, il me restait en tête une question. C'est quoi et ça en est où btrfs ? Comment ça se prononce?

        Bon après il m'a fallu quatre demi-secondes pour trouver le journal de pg, qui m'était sorti de la mémoire (le journal, pas pg), et c'est sûr que c'est pas énorme. Mais je trouvais que le lien aurait complété agréablement ton journal.

        Voilà c'est tout.

    • [^] # Re: Presque bien

      Posté par  . Évalué à 10.

      Quel est l'intérêt de toujours se rapporter aux news/journaux de patrick_g ?
      En effet, ceux-ci sont d'une grande qualité et intéressants à lire mais il ne faudrait pas arriver à ce que des contributeurs potentiels soient bloqués devant le fait que leurs articles ne soient pas du "niveau" de ceux de patrick_g et que seul ce dernier ait le courage d'en proposer.
      Le journal d'IsNotGood est intéressant et répond bien à la définition de journal selon moi, merci à lui.

      • [^] # Re: Presque bien

        Posté par  . Évalué à 3.

        C'est vrai qu'il est très bien. Manquait juste une petite traduction,mais elle est dans les commentaires. Donc merci !

      • [^] # Re: Presque bien

        Posté par  . Évalué à 2.

        C'est juste le stakhanovisme à la sauce LinuxFr, et patrick_g est notre Alekseï .

        • [^] # Re: Presque bien

          Posté par  . Évalué à 2.

          Ouais mais lui ne triche pas ! Quoique, remarque, peut être ... tout un mythe s'effondre !

          • [^] # Re: Presque bien

            Posté par  . Évalué à 9.

            Qui te dit que patrick_g n'est qu'un seul homme ?
            Cela te semble crédible le gars qui va faire une grosse dépèche sur le noyau juste avant un entretiens, et puis qui va se faire une petite dépèche sur OpenOffice le midi en prenant son café ?
            Moi, je dis qu'ils sont plusieurs ! Ce sont toutes les élites du site qui se sont regroupés pour créer un modèle à suivre pour tout les LinuxFriens.

            • [^] # Re: Presque bien

              Posté par  . Évalué à 6.

              Bon, il faut que je l'avoue maintenant. Je ne peux plus supporter ce poids sur mes épaules.

              Je suis le nègre de patrick_g. (BHL ne payait pas assez)

            • [^] # Re: Presque bien

              Posté par  . Évalué à 10.

              Qui te dit que patrick_g n'est qu'un seul homme ?

              Oui, si ça se trouve, c'est une infinité de singes sur des machines à écrire...

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # linuxen.org

    Posté par  . Évalué à -1.

    LinuxFR, c'est agreable parce que ça permet de lire des nouvelles sur linux, en français...

  • # Question bête...

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Bonsoir

    Merci pour cette info IsNotGood!!!
    C'est cool de savoir ce qui va nous arriver.

    Quelqu'un à une idée du temps qu'il a fallut pour développer ext4?
    Sauf erreur vous croyez que l'on peut considérer qu'à partir de 2009 on sera tous sous ext4?

    Cordialement Thierry

    • [^] # Re: Question bête...

      Posté par  . Évalué à 3.

      > Quelqu'un à une idée du temps qu'il a fallut pour développer ext4?

      Il était dans le 2.6.19 qui est sorti en ... (?).
      Bref, ça a pris plus de temps que prévu (comme toujours j'ai envis d'ajouter).

      > Sauf erreur vous croyez que l'on peut considérer qu'à partir de 2009 on sera tous sous ext4?

      Le "tous" est de trop.
      F9 proposait ext4. F10 va évidemment le proposer (faut ajouter "ext4" lors de l'installation). F10 sortira dans quelques semaines. Comme l'indique Theodore Ts'o ext4 est déjà utilisé (tout en étant dans une phase de développement intensive). Mais des tests de plus par des "vrais" utilisateurs serait un plus très très apprécié par les développeurs (qu'on ne remercira jamais assez).
      Perso, je vais passer à F10 et aussi ext4 même si c'est un risque (on ne fait d'omelette sans casser des oeufs).
      Ext4 a un niveau de maturité qui lui permet d'être indiqué comme stable dans 2.6.28 (F10 sortira probablement avec un 2.6.27 avec les patchs pour 2.6.28). C'est le moment de tester, les développeurs seront très sensibles à tout problème.

      C'est le moment de tester ext4 ! Avec au moins un 2.6.27 évidemment et sautez sur le 2.6.28 lorsqu'il sortira.

      • [^] # Re: Question bête...

        Posté par  . Évalué à 1.

        Mais des tests de plus par des "vrais" utilisateurs serait un plus très très apprécié par les développeurs (qu'on ne remercira jamais assez)

        Il serait bon de préciser les divers tests auxquels les utilisateurs doivent se prêter pour rapporter des infos pertinentes.

        Quelles les particularités d'Ext4 qui fassent qu'on doivent jouer avec plus précisément?

      • [^] # Re: Question bête...

        Posté par  (site web personnel, Mastodon) . Évalué à -1.

        Salut

        ok pour tester...
        par contre je vais pas le faire sur mon pc de bureau mais sur ma debian lenny à la maison, mon seul problème c'est qu'il faut je trouve le bon package...

        allez zou au taffe.

        merci encore pour l'info
        thierry

        mince pourquoi j'ai l'impression que le noyau de ma debian lenny à stoppé à 2.6.26, hum hum hum...

    • [^] # Re: Question bête...

      Posté par  . Évalué à 2.

      Tu sais qu'il y a des gens qui ne réinstalle pas completement leur OS pendant des années.
      Ext3 marche bien sur mon poste de travail, je vais pas m'amuser à formater juste pour avoir un nouveau fs qui ne me sert à rien.

      • [^] # Re: Question bête...

        Posté par  . Évalué à 9.

        > qui ne me sert à rien.

        qui ne t'apporte rien de plus (petite nuance)

      • [^] # Re: Question bête...

        Posté par  . Évalué à 2.

        Petite précision, ext4 est backward compatible avec ext3...
        celà signifie que si tu es sur une partition ext3, tu peux la monter comme une partition ext4 sans formatter... ils ont un format commun. En fait ext4 est un fork de ext3.
        bien sûr ext4 ajoute plusisurs nouveautés dont "extents" qui permet d'avoir un disque moins fragmenté au final. et si l'on utilise pas ces nouveautés, ext4 est forward compatible avec ext3, à savoir que la partition ext4 peut être monté comme une partition ext3...

        • [^] # Re: Question bête...

          Posté par  . Évalué à 3.

          intéressant ça...
          ça veut dire qu'une partition ext4 est physiquement identique à une partition ext3 ? Qu'il y aurait donc plus de différence (dans la partition) entre ext2 et ext3 qu'entre ext3 et ext4 et qu'un système nouvellement installé avec ext4 sera pareil qu'un système installé en ext3 qui monte la partition en ext4 ensuite ?

          Si c'est cela, je pense monter mon / en ext4 dès que possible, et pour le /home on attendra un peu, même si les fichiers les plus importants sont sauvegardés avec unison et permettraient de détecter une corruption, les moins importants sont moins régulièrement sauvegardés...

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: Question bête...

            Posté par  (site web personnel) . Évalué à 2.

            > Qu'il y aurait donc plus de différence (dans la partition) entre ext2 et ext3

            Euh, moi j'ai passé mes partitions ext2 en ext3 sans formattage à l'époque ! Et il est possible de monter les partitions ext3 en ext2 sans problème (en perdant évidement la journalisation).

            • [^] # Re: Question bête...

              Posté par  . Évalué à 6.

              en fait je pensais que c'était juste le pilote qui modifiait des choses dans la gestion du système de fichier, qui restait presque le même, mais alors que ext3 apportait la journalisation par rapport à ext2, ext4 avec les "extents" apportera de nouvelles choses du même accabit, aussi il y aura finalement beaucoup de différences avec ext3, et si la rétro compatibilité est possible, en revanche il est précisé que si la partition ext4 utilise des extents, il ne sera pas possible de la monter en ext3 par exemple.

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Question bête...

        Posté par  . Évalué à 2.

        Pareil, je suis depuis 4, 5ans avec ReiserFS, même si son developpement n'a guère avancé depuis belle lurette. Mais en même temps, il est d'une stabilité jusqu'à présent sans faille pour moi.

        Je parle de reiserfs 3.6 bien sûr.

        En tout cas, Ext3 ne m'a jamais emballé contrairement à Ext4 qui sembler sentir très bon. :)

  • # Utilisable ?

    Posté par  . Évalué à 1.

    Est-ce que ça veut dire que ext4 devient utilisable pour une utilisation de tout les jours ?

    • [^] # Re: Utilisable ?

      Posté par  . Évalué à 4.

      Franchement, je serai prudent. Je commencerai par utiliser une partition dédiée pour faire des tests de rien du tout sans risquer de perdre ses données.

      « ext4 a mangé mon /home », je le vois venir assez gros somme toute. C'est un peu risqué de passer ses partitions en ext4 pour une première publication dans la branche stable.

      http://ext4.wiki.kernel.org/index.php/Ext4_Howto

      • [^] # Re: Utilisable ?

        Posté par  (site web personnel) . Évalué à 8.

        Il vaut mieux (je pense) passer la partition racine en ext4 ... comme ça si on a un problème il suffit 'juste' de réinstaller le système. Pour le homedir, c'est plus gênant.

      • [^] # Re: Utilisable ?

        Posté par  (Mastodon) . Évalué à 3.

        c'est bien beau une partition dédiée pour faire des tests, mais dans le cas d'une utilisation "normale" d'un pc, tu ne perds pas ton temps à faire des tests protocolés.

        Vous ne faites jamais de backups ?

        Avec une simple et bonne politique de backup, y'a peu de risque. Un bête rsnapshot toutes les heures sur un second disque externe, c'est très facile sur un desktop. Sur un laptop qui se trimballe à droite et à gauche, c'est moins faisable mais dans ce cas la, un backup par soir + une clé usb pour sauver les fichiers importants sauvegardés pendant la journée et c'est bon.

        • [^] # Re: Utilisable ?

          Posté par  . Évalué à 9.

          Sauf que si la technologie est foireuse, tu risque de mettre plusieurs semaines ou mois avant de te rendre compte que tes fichiers les moins utilisés sont corrompus...
          Un disque qui lache, on s'en rend compte. Une corruption silencieuse est plus traitre.

          • [^] # Re: Utilisable ?

            Posté par  (Mastodon) . Évalué à 3.

            Les HIDS, c'est pas fait pour les chiens :)

            Et c'est pour ça que j'ai proposé rsnapshot. Il faut bien sur avoir une politique de rétention correcte de ses backups. Mais aux prix du TB actuel, c'est pas dur d'avoir plusieurs semaines de rétention.

            Avec un disque externe de 1TB à 150 balles, tu peux backuper un certains nombre de fois le petit disque de 120GB de ton laptop. Et si tu utilises ext4 à la fois pour ton système et tes données, il y'a de fortes chances que si le fs engendre des corruptions, tu te rendra compte avec un hids qu'il se passe des choses bizarres sur tes fichiers.

            • [^] # Re: Utilisable ?

              Posté par  . Évalué à 7.

              donc, concretement, il faut:
              - 1 disque de backup plutot couillu (mini un tera)
              - faire le backup de tout ca toute les heures. Ca marche comment, ca sauve juste le diff, ou le fichier complet?
              Un peu lourd le backup aussi regulier, mais bon, admettons.

              En cas de corruption sliencieuse:
              - Pallier au plus presse en restaurant uniquement les fichiers dont on a besoin la main'nant toussuite en fouillant dans les backup pour retrouver la derniere version non corrompue
              - Puis se fader TOUS les fichiers un par un pour verifier leur integrite, et en cas de pb se retaper tous les backups pour restaurer la bonne version.

              Ok, mais en pratique, comment tu fais pour verifier l'integrite des fichiers?
              Sur du binaire, tu peux raisonnablement penser que si ton appli ne peut pas l'ouvrir, ton fichier est flingue. Et encore, tu peux ne pas avoir de chance et avoir perdu des donnees sans corrompre ton fichier.
              Sur du texte, tu fais comment? Genre si t'as juste qq (kilo) octets qui ont saute? Tu relis tout le fichier et tu verifies qu'il est comme il etait avant?
              Si t'as qq centaines de Mo de donnees, tu passes 3 jours a tout verifier?

              Ca me parait quand meme particulierement ose comme manip, autant sur le systeme, c'est pas bien grave, au pire tu perds 2 heures a tout reinstaller, c'est pas la fin du monde.
              Sur des donnees, faut soit avoir particulierement confiance dans le nouveau FS, soit avoir tres peu de donnees (mais dans ce cas, le test est il pertinent?), soit avoir des donnees dont on n'a pas grand chose a faire.

              Bref, tu vois ou je veux en venir: un fs, ca se teste exhaustivment avant de l'amener a l'utilisateur final, tu lui demandes pas de faire le cobaye au risque de flinguer tout ce qu'il a sur sa machine.

              Et je dit ceci independamment de la stabilite d'ext4, dont je n'ai aucune idee, c'est juste ta theorie de tester le fs chez l'utilisateur qui me fait bondir au plafond.

              • [^] # Re: Utilisable ?

                Posté par  (Mastodon) . Évalué à 5.

                > donc, concretement, il faut:
                >- 1 disque de backup plutot couillu (mini un tera)

                bof la taille, ça dépend du disque de ton pc. Il faut de toute façon que celui de backup soit plus gros et je dirai qu'un minimum serait 2 à 2.5x la taille si tu veux avoir une longue rétention.

                >- faire le backup de tout ca toute les heures. Ca marche comment, ca sauve juste le diff, ou le fichier complet?
                > Un peu lourd le backup aussi regulier, mais bon, admettons.

                rsnapshot pour le citer comme exemple, utilise rsync accouplé avec un système de hardlinks pour ne pas backuper 2x le même fichier. Il fait donc une sorte de déduplication : tu ne fais réellement que des backups différentiels, mais tu vois au final une image complète de ton disque comme si tu ne faisais que des full.

                > Ok, mais en pratique, comment tu fais pour verifier l'integrite des fichiers?
                > Sur du binaire, tu peux raisonnablement penser que si ton appli ne peut pas l'ouvrir, ton fichier est flingue. Et encore, tu peux ne pas avoir de chance et avoir perdu des donnees sans corrompre ton fichier.
                > Sur du texte, tu fais comment? Genre si t'as juste qq (kilo) octets qui ont saute? Tu relis tout le fichier et tu verifies qu'il est comme il etait avant?
                > Si t'as qq centaines de Mo de donnees, tu passes 3 jours a tout verifier?

                J'ai cité plus haut l'utilisation d'un HIDS. C'est un outil qui maintient une base de donnée de tous tes fichiers et qui vérifie leur intégrité à intervalle régulière. Grâce à un système de règle tu peux vérifier des choses comme des modifications de checksums de tes fichiers, des changements d'inodes suspects, des modifications de mtime,ctime,atime. Il t'envoie des rapports avec les choses qui ont changés.

                A la base c'est fait pour vérifier qu'il n'y a pas eu d'intrusion, qu'un fichier n'a pas été remplacé par un rootkits, mais ça peut très bien être utilisé pour détecter des pannes disques. J'ai déjà découvert des problèmes de corruptions de données avec ça.

                > Bref, tu vois ou je veux en venir: un fs, ca se teste exhaustivment avant de l'amener a l'utilisateur final, tu lui demandes pas de faire le cobaye au risque de flinguer tout ce qu'il a sur sa machine.

                Note que je n'ai pas dit que c'était quelque chose qu'il fallait demander à n'importe qui. J'affirme juste que moyennant un minimum de précautions, un utilisateurs averti peut tester un nouveau fs sans prendre de grands risques.

                ça suppose donc que :
                -perdre 1h de travail sur tes données n'est pas très grâve pour toi. Si tu utilises ton pc dans le cadre de ton travail, on évitera donc.
                -devoir réinstaller un système au cas où tu as eu des problème ne te dérange pas trop.
                -avoir une politique de backup solide, mais ça à mon humble avis tout le monde devrait le faire. Si tu considère tes données précieuses, ton home devrait de toute manière être sauvés régulièrements. Un disque ça pète généralement avant que SMART s'en rende compte...
                -utiliser un hids, et le plus important : (bien) lire ses rapports/alertes et avoir une bonne connaissance de ce qui change sur ton système entre 2 vérifications (ai-je fais une mise à jour ? quels fichiers sont impactés ?).

                Faire du test, ce n'est donc pas juste télécharger le truc et attendre que ça se passe. Mais ce que j'affirmais plus haut, c'est que si tu te dis que tu va utiliser juste une partoche de test, je sais qu'en pratique sur ton pc perso tu ne l'utiliseras probablement pas assez (parce que pas la même confiance) pour te rendre compte d'un éventuel bug...L'idéal est donc de l'avoir partout, avec les précautions d'usage, pour avoir plus de (mal)chance de tomber sur un problème.

                quelques liens :
                rsnapshot: http://www.rsnapshot.org

                quelques HIDS :
                AIDE : http://www.cs.tut.fi/~rammer/aide.html
                Samhain : http://la-samhna.de/samhain/
                Osiris : http://osiris.shmoo.com/

                • [^] # Re: Utilisable ?

                  Posté par  . Évalué à 1.

                  > Il fait donc une sorte de déduplication

                  Oui, notez qu'il s'agit de déduplication par fichier (et non par blocs comme sur du NetApp par ex.).

                  > rsnapshot: http://www.rsnapshot.org

                  Avec des fonctionalités équivalentes (hardlinks pour les fichiers identiques, y compris identiques entre plusieurs machines), mais plus carré et plus complet, il y a backuppc :

                  http://backuppc.sourceforge.net/

                  > Samhain : http://la-samhna.de/samhain/

                  J'utilise ce dernier depuis un moment (pas encore eu le temps de changer), et je le déconseille à tout le monde (ie. ceux qui comme moi risquent d'être convaincus par http://la-samhna.de/library/scanners_2004.html ) :
                  - Les fonctionalités interessantes sont déportées sur une interface proprio (beltane) aux dépendances usinagazesques. Le dev. veut faire son beurre en vendant cette interface.
                  - Dans la version de debian etch, les outils manuels de mise à jour, checks, etc. ne marchent tout simplement pas. Il faut attendre que le daemon se debrouille :
                  # echo pouet > /bin/ps
                  # samhain --foreground -t check
                  # <-- rien, ni dans les logs, ni envoyé par mail, ...

                  À ceux qui utilisent d'autres HIDS (Aides, Osiris, ...), auriez vous des retours d'expérience à nous transmettre ?

                  • [^] # Re: Utilisable ?

                    Posté par  (Mastodon) . Évalué à 3.

                    Samhain fonctionne très bien dans mon environnement. Les dépendances de Beltane ne m'ont pas paru si gênantes que ça, tu ne l'installes pas sur tous tes clients de toute manière. Le scanner a toujours bien fonctionné chez moi. Par contre je n'ai pas utilisé une version prépackagée, j'ai tout compilé moi-même (de même que apache, php, mysql et les autres dépendances de beltane). Le problème provient peut-être de debian ? Le gros plus c'est de pouvoir centraliser les configs et baseline des clients.

                    AIDE est ce qui se rapproche le plus de la version basique de tripwire. Pour une ou 2 machines isolées, c'est bien. ça juste marche™. Par contre pas d'architecture client/serveur.

                    Osiris j'ai voulu tester brièvement. L'interface est uniquement sur console apparemment et j'avais des problèmes à mettre en place la relation entre le client et le serveur. Mais comme samhain fonctionnait, je n'ai pas chercher à resoudre ce problème.

  • # Ext4 et Reiser

    Posté par  . Évalué à 10.

    Ext4 va sortir !!!

    En tout cas, Reiser il est pas près de sortir lui...

    Ok, je ---> []

  • # File systems et supports physiques

    Posté par  . Évalué à 5.

    Je me demande à quel point le support physique (disque dur) est intégré dans le modèle de ces file systems. Cela sous-entend certaines optimisations spécifiques à ce support. Pourtant, il y a un changement depuis quelques mois avec l'arrivée des "disques" SSD (mémoires Flash) qui eux nécessitent d'autres types d'optimisation. Il y a d'ailleurs UBIFS qui vient de sortir pour travailler directement avec cet autre support physique.

    Les "disques" SSD devraient mettre une à deux années pour atteindre les capacités des HDD actuels et commencent déjà à les dépasser en performance (Intel X25E avec des débits R/W de 250MB/s, c'est-à-dire 2 fois mieux que le meilleur des HDD), et ce n'est qu'un début! Comme il faudra plusieurs années pour développer btrfs, je me demande si ce n'est pas déjà trop tard...

    • [^] # Re: File systems et supports physiques

      Posté par  . Évalué à 6.

      A priori pas de problèmes pour btrfs:
      http://oss.oracle.com/pipermail/btrfs-devel/2008-February/00(...)

      • [^] # Re: File systems et supports physiques

        Posté par  . Évalué à 3.

        Pourtant, comme le dit patrick_g (http://linuxfr.org/2008/04/04/23938.html ):

        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. [...].
        Cet 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         [patrick_g parle ici d'UBIFS].

        Ce que je voulais donc dire, c'est qu'il y a beaucoup d'efforts fournis pour les file systems sur HDD mais je ne suis pas sûr que ce soit la meilleure direction à prendre. Même si btrfs accepte les SSD comme tu le fais justement remarquer, ribwund.

        • [^] # Re: File systems et supports physiques

          Posté par  . Évalué à 4.

          Sauf que tu peux pas dialoguer directement avec la flash sans passer par le micro controlleur avec les ssd, sd-card, clef usb, ...

          Et a propos d'ubifs : http://www.linux-mtd.infradead.org/doc/ubifs.html#L_raw_vs_f(...)

          • [^] # Re: File systems et supports physiques

            Posté par  . Évalué à 1.

            C'est vrai Matthieu, il faudra que les fabricants de SSD acceptent que l'on puisse accéder directement à la mémoire (en RAW, je crois), plutôt que de passer par le firmware du bouzin. Cela devrait alors sérieusement augmenter les performances des SSD.

            • [^] # Re: File systems et supports physiques

              Posté par  . Évalué à 3.

              C'est vrai Matthieu, il faudra que les fabricants de SSD acceptent que l'on puisse accéder directement à la mémoire (en RAW, je crois), plutôt que de passer par le firmware du bouzin.
              C'est plus compliquer que ca : comment tu accedes a la memoire flash en RAW a travers des transport fait pour des disques dur : protocole ATA (pour les ssd), scsi (pour les clef usb), commandes sd-card ?

              Cela devrait alors sérieusement augmenter les performances des SSD.
              Pas sur : encore faut il savoir exploiter l'architecture des mémoire flash présente : sont-elle mises en //, ...

              Si tu lis le lien du mon post au dessus :

              SSD drives are probably very different to eMMC, MMC/SD etc. We have not worked with SSD drives. They are expensive and they probably have powerful CPUs inside, which run complex firmware which is probably getting things righ.

              Theoretically, UBIFS may do better job, because it knows much more information about the files than FTL. For example, UBIFS knows about deleted files, while FTL does not, so FTL may do unneeded work trying to preserve the sectors belonging to deleted files. However, some FTL devices support "discard" requests and may benefit from the file-system hints about unused sectors. Nevertheless, in general, UBIFS should do better job on a bare NAND, than a traditional FS on an FTL device with a similar NAND chip. On the other hand, FTL devices may include multiple NAND chips, highly parallelise things and provide fast I/O. Probably SSD is a good example. But this may affect the cost.


              Ce qui m'inquiéte plus les ssd c'est la robustesse, pas les perfs. La gestion des NAND (et notament de MLC) est super complexe. En effet c'est de la flash pas chére qui arrive a avoir des capacité correcte, mais c'est de la merde : tu peux avoir des zones foireuses (bad block), avoir des zones qui deviennent mauvaises au cours de la lecture (bit flit), avoir des zones qui deviennent mauvaises après un certains nombre de cycle d'effacement, une granuralité d'effacement/écriture qui n'est pas forcement pratique, ....

              Sans compter qu'a mon boulot, on a utilisé des Nand avec ftl embarqué, et on a eu plein de soucis de corruption (voir meme de destruction).

        • [^] # Re: File systems et supports physiques

          Posté par  . Évalué à 4.

          Si tu lis la suite du thread tu verras qu'il y a un mode spécial pour SSD dans btrfs, et donc ce n'est pas juste qu'il accepte le SSD. Par exemple pour le wear leveling, d'après ce que j'ai compris, le fait de repartir et de dupliquer les superblocs aide beaucoup.

          • [^] # Re: File systems et supports physiques

            Posté par  . Évalué à 1.

            C'est vrai, ribwund. À la fin du post:

            >
            > So, is the design of btrfs a good match for the peculiarities of SSDs ?
            >

            Yes, because Btrfs is copy on write it is able to always cluster metadata and
            data writes in an optimal fashion on the SSD. On traditional storage you get
            very bad performance with this type of allocation model because it will have
            many more seeks on reads. But with SSD, there is no read penalty.

            Je n'ai malheureusement pas l'impression que Btrfs utilise la bibliothèque UBI, maintenant intégrée au kernel et sur laquelle UBIFS est basée.

            Je ne dénigre pas Btrfs, disons qu'il serait bien adapté s'il était en production maintenant, mais dans un an voire deux, il est possible qu'il ne soit plus aussi intéressant.

            • [^] # Re: File systems et supports physiques

              Posté par  . Évalué à 3.

              Je n'ai malheureusement pas l'impression que Btrfs utilise la bibliothèque UBI, maintenant intégrée au kernel et sur laquelle UBIFS est basée.

              UBI c'est pour des flash raw, ce qui n'est pas le cas des disques ssd.

  • # next generation ?

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Je n'ai pas tout lu, mais cela implique quoi la nouvelle génération ? Comparé à zfs ou à hammerfs par exemple, qui sont eux aussi "nouvelle génération"

    • [^] # Re: next generation ?

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      C'est pour ceux qui n'ont pas goûté à ZFS !

    • [^] # Re: next generation ?

      Posté par  (Mastodon) . Évalué à 5.

      c'est la même chose, mais pour les gens qui utilisent un os sous une licence peu libre comme la GPL.

    • [^] # Re: next generation ?

      Posté par  . Évalué à 1.

      Je ne le comprend pas comme toi.
      Les experts systèmes de fichier ont évalué les nouveaux besoins. Ext[34] est le standard de Linux. Ext[34] ne peut pas prendre en charge les nouveaux besoins. Il faut donc partir sur une autre base (qui sera probablement btrfs).
      Que ZFS en est une plus grosse n'est pas la question ici.

  • # Comparaison des systèmes de fichier

    Posté par  (site web personnel) . Évalué à -5.

    J'attends le jour ou patrick_g nous publiera une magnifique dépèche qui comparera tout les systèmes de fichiers "next gent". Vu comment ce monde là est bouillonant d'idées, ça va être dur de faire son choix .

Suivre le flux des commentaires

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