Btrfs intègre le noyau Linux dès la prochaine version 2.6.29

Posté par  (site web personnel) . Modéré par Sylvain Rampacek.
Étiquettes :
44
11
jan.
2009
Noyau
Btrfs est un système de fichier transactionnel de type 'Btrfs sur nos postes de travail.

Aller plus loin

  • # Passage d'ext4 en btrfs

    Posté par  . Évalué à 7.

    À noter également, il est prévu de créer un outil pour faire la migration d'une partition ext4 en btrfs...
    Par contre je suis navré, j'ai lu ça sur lwn.net, mais je ne retrouve plus le lien.

  • # XFS roulaize des papas ours !

    Posté par  . Évalué à -9.

    tout est dans le titre.

    Et sinon il fait beau chez vous ?

    Poil.

  • # Btrfs

    Posté par  . Évalué à 6.

    Je ne comprends pas pourquoi ils ont préféré le mot "Btrfs" plutôt que le nom entier "BetterFS". C'est moche à prononcer.

  • # SSD

    Posté par  . Évalué à 2.

    Ça c'est une excellente nouvelle!

    Son développement seras plus rapide.

    Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?
    Je mettais arrêté à ça : http://linuxfr.org/2008/04/04/23938.html

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: SSD

      Posté par  . Évalué à 8.

      Je pense que c’est pas pareil, la dépêche de Patrick_G parlait des systèmes de fichier pour écrire directement sur la mémoire flash, sur les SSD il y a une couche d’abstraction matérielle.

      • [^] # Re: SSD

        Posté par  . Évalué à 3.

        Et je crois que tout les SSD 'hautes performances' qui sont sorti recement se comporte comme des disque(*) et qu'on utilise donc des systeme de fichier 'normaux' dessus.

        *: Ce qui explique d'ailleur pourquoi ils ont parfois des performances en écritures aléatoire pas terribles ces SSD quand ils commencent a être rempli..

        • [^] # Re: SSD

          Posté par  . Évalué à 4.

          Pas seulement, toutes les cartes SD/CF/..., clés USB, et SSD, contiennent un FTL (en:Flash_Translation_Layer) qui les font apparaître comme un périphérique de type "bloc", c'est à dire typiquement fait pour les disques durs et autres périphériques magnétiques. Bref, c'est complètement inadapté (il vaudrait mieux pouvoir y accéder comme un périphérique MTD (en:Memory_Technology_Device)) mais c'est comme ça. Et donc on ne peut (enfin, on pourrait, mais il vaut mieux pas) que utiliser des FS faits pour les disques.

          • [^] # Re: SSD

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

            Il serait toujours possible de faire du wear leveling en évitant d'écrire toujours les mêmes blocs.

            Les SSD ont un autre énorme problème : la taille du bloc d'écriture. Il fait autour de 128Ko. Une écriture de 1 octets provoque une écriture de 128Ko. L'effet est d'avoir une vitesse d'écriture aléatoire de petit bloc très très lente. Certain SSD tombe à 4 écritures/s pour des blocs de 4ko, soit une latence de 250 ms ! On est loin des 0.1 ms promis !

            Les 2 techniques pour limiter cette effet est la multiplication des "channels" de mémoire flash sur le contrôleur (4 chez certain, 10 pour celui d'intel) et l'ajout de mémoire cache SDRAM (j'ai déjà vu 32Mo).

            Cette lenteur est très visible lors de la décompression d'un gros tar ou la copie de répertoire. La vitesse de décompression d'un noyau pourrait être un bon bench :)

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

            • [^] # Re: SSD

              Posté par  . Évalué à 3.

              Heu, il me semble que tu fais une petite erreur, on est obligé d'effacer un erase block si on veut écrire dans un endroit déjà écrit auparavant, en effet. Mais une fois que cette zone a été effacée (128Ko c'est pour donner un ordre d'idée je suppose, mais ça doit être à peu près ça), on peut y écrire en plusieurs fois, par page de 4 ou 8Ko environ (encore variable selon les technos/constructeurs/...), jusqu'à la remplir. Sinon ce serait vraiment la galère.

              Sinon, pour les problèmes de perf, je pense aussi que les algos de wear-leveling jouent beaucoup sur la lenteur : si c'est un algo merdique (vu comme le domaine doit être blindé de brevets, aussi ...), le fait d'écrire plein de petits blocs va vraiment le faire ramer. Ça plus les problèmes d'erase block, effectivement ça ne donne pas un joli résultat.

              Enfin, en ce qui concerne la SDRAM, j'avais lu qu'elle ne servait pas de cache, mais de mémoire "opératoire" pour le chip qui fait le wear-leveling ; il y stocke diverses infos pour faire ses calculs, mais ce n'est pas un cache de données (à vérifier).

              Enfin bon, comme d'hab, dans un domaine ou les constructeurs sont peu bavards, on ne peut pas faire mieux que de spéculer ...

              • [^] # Re: SSD

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

                Mais une fois que cette zone a été effacée (128Ko c'est pour donner un ordre d'idée je suppose, mais ça doit être à peu près ça), on peut y écrire en plusieurs fois, par page de 4 ou 8Ko environ (encore variable selon les technos/constructeurs/...), jusqu'à la remplir. Sinon ce serait vraiment la galère.

                Cela explique la chute de perf quand le SSD se remplit. D'après les white paper de samsung (?), ils agissent par bloc de 4Mo, dans lequel il font "tourner" les blocs. donc, si on écrit beaucoup dans un bloc de 4Mo, il tourne beaucoup, et il y a plus d'effacement/écriture.

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

                • [^] # Re: SSD

                  Posté par  . Évalué à 3.

                  Nan, les 4Mo c'est la taille de la zone sur lequel il wear-level. Tu écris par page ou bloc (ça dépend de la terminologie) de 4Ko environ, mais tu dois effacer par erase block de 128Ko environ, et la carte (puisque dans le white paper on parle de carte CF il me semble) wear-level par zone de 4Mo environ (tous ces chiffres doivent varier en fonction du constructeur, de la techno et de la taille de la carte).

              • [^] # Re: SSD

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

                Pour avoir l'information complète, il faudrait donc, la décompression en boucle d'un noyau linux jusqu'au remplissage du disque:)

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

                • [^] # Re: SSD

                  Posté par  . Évalué à 2.

                  Même pas, puisque les cartes flash gardent de coté des blocs de secours en cas de défaillance de certains. J'ai réfléchi à ça car je compte utiliser des CF comme disque principal, mais c'est assez chaud d'imaginer un "bench" qui permetterai de connaître les caractéristiques de la carte (j'ai déjà vu un mec faire ça, mais j'ai perdu le lien ...)

                  • [^] # Re: SSD

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

                    Je ne voix pas en quoi les blocs de secours entre en jeux. Ils ne sont là qu'en cas de défaillance, et ne rentre en jeu qu'en cas de soucis. Je n'imagine pas faire un teste de robustesse :)

                    Quel information de performance manquerait avec un "time tar xzf" en boucle jusqu'à remplissage de la partition ?

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

                    • [^] # Re: SSD

                      Posté par  . Évalué à 2.

                      En fait, j'ai mal répondu parce que je me rend compte que je n'ai pas compris la question : tu veux savoir quoi exactement avec ce test ?

          • [^] # Re: SSD

            Posté par  . Évalué à 10.

            Le fait que les supports SSD sont tous en mode FTL et non en MTD ne serait-il pas dû à un OS massivement majoritaire qui a tendance à imposer sa vision des choses et qui ne sait déjà pas gérer beaucoup de FS, alors lui demander de savoir gérer un périphérique autrement... ?
            (vraie question, avec quelques morceaux de trolls dedans quand même)

            • [^] # Re: SSD

              Posté par  . Évalué à 3.

              Entre autre, mais les problèmes de compatibilités ne s'arrêtent pas à Windows..

            • [^] # Re: SSD

              Posté par  . Évalué à 3.

              Oui et non.

              Oui, c'est clair que comme d'hab ce n'est pas MS qui va faire avancer les choses dans le sens des technologies futures ouvertes pour tout le monde (je les aurai bien vu sortir un truc rien qu'à eux .... tiens, d'ailleurs, voir les actus récentes sur l'ExFAT, le FS standard sur les nouvelles cartes SDXC, utilisable uniquement avec Vista SP1 ...). Et que tant qu'il ne se décident pas à bouger, personne ne le fera (enfin si, les libristes, mais tout le monde va encore leur rire au nez).

              Par contre, le fait de réutiliser les connexions standards des périphériques magnétiques (ATA et SATA) est quand même un gros avantage, en ce qui concerne les standards matériels.

              FTL et MTD ne sont pas vraiment des "modes". FTL c'est le nom de la puce (ou du mécanisme) qui traduit les commandes reçues, spécifiques au périphériques de type "bloc", en quelque chose qui va écrire sur les puces NAND.

              Et MTD c'est le nom, sous linux, qu'ont les périphériques NAND qui sont accessibles par leur interface "native" : on ne peut pas choisir d'écrire un bloc au hasard, il faut effacer un erase block si quelque chose avait été écrit auparavant. Et le soft doit aussi gérer lui-même le wear-leveling : c'est un peu demandeur en ressources, mais ça permet de choisir _sa_ technique, et surtout d'évoluer au rythme su soft, et pas du hard.

              Dommage que la Flash ne soit accessibles directement comme ça que sur les périphériques embarqués à mémoire inamovible.

              PS: il n'existe pas aujourd'hui à ma connaissance de connexion matérielle standard pour relier de la Flash à un ordinateur. C'est con...

              • [^] # Re: SSD

                Posté par  . Évalué à 2.

                >>Dommage que la Flash ne soit accessibles directement comme ça que sur les périphériques embarqués à mémoire inamovible.<<

                Ce qui est curieux c'est que la Flash ne fournisse pas les deux modes, disque dur pour la compatibilité et 'natif' pour les performances, j'imagine que les quelques cents d'Euros en couts supplémentaire pour le contrôleur doivent être considéré comme inutile..

                >>PS: il n'existe pas aujourd'hui à ma connaissance de connexion matérielle standard pour relier de la Flash à un ordinateur. C'est con...<<

                Bin c'est surtout récent cette mode d'avoir des 'disques Flash' donc c'est normal de réutiliser l'existant (SATA / PATA)..

                Mais on peut espérer qu'à terme les connexions soit directement sur du PCIExpress..

                • [^] # Re: SSD

                  Posté par  . Évalué à 2.

                  Ce qui est curieux c'est que la Flash ne fournisse pas les deux modes, disque dur pour la compatibilité et 'natif' pour les performances, j'imagine que les quelques cents d'Euros en couts supplémentaire pour le contrôleur doivent être considéré comme inutile..
                  Heu ... le plus gros problème, c'est que le protocole ATA (et donc SATA) n'est simplement pas fait pour les périphériques non-"block". Ce n'est pas géré dans le protocole, donc ça ne peut pas être géré par le SSD.

                  Alors après, comme toujours, on pourrait inventer un petit "hack" pour faire passer des commandes MTD classiques par de l'ATA, mais à ma connaissance ça n'a jamais été fait.

                  Mais on peut espérer qu'à terme les connexions soit directement sur du PCIExpress..
                  Il faut voir ce que tu veux dire par "PCIExpress", parce que mettre une NAND connectée à du PCIe, ça veut mettre un contrôleur qui utilisera un certain protocole de communication avec l'hôte. Et pour que ce soit pas le bordel, il faudrait que ce protocole soit standarisé. Vu comme est partie l'industrie (i.e. pas dans cette voie, à part quelques exceptions), je ne pense pas que ça arrivera (tous ceux qui voudraient s'y lancer aujourd'hui auront quelques bons wagons de retard sur la concurrence si leur truc ne marche pas "out of the box").

                  • [^] # Re: SSD

                    Posté par  . Évalué à 2.

                    >>Alors après, comme toujours, on pourrait inventer un petit "hack" pour faire passer des commandes MTD classiques par de l'ATA, mais à ma connaissance ça n'a jamais été fait.<<

                    Oui, c'est a ça que je pensais comme type de bidouille, c'est quand même un peu rallant de faire d'avoir des perf en écriture aléatoire sous-optimale a cause de limitations dans le micro-contrôleur qui gere le SSD alors que le CPU pourrait aider..

                    Pour ce qui est du SSD sur PCIExpress, il y en a qui bosse dessus, après est-ce que cela va prendre ou pas, pas la moindre idée..
                    http://www.theregister.co.uk/2008/10/14/fusionio_pcie_connec(...)

          • [^] # Re: SSD

            Posté par  . Évalué à 7.

            Bref, c'est complètement inadapté (il vaudrait mieux pouvoir y accéder comme un périphérique MTD

            Linus Torvalds n'est pas d'accord :

            « The only sane flash model is one where the hardware itself
            does the block remapping.

            And no, this is not about "most filesystems" or about any
            majority voting. It's a simple technical fact.

            The simple fact is that exposing the internal flash
            model to any external software is simply insane. [...] »

            http://realworldtech.com/forums/index.cfm?action=detail&(...)

            • [^] # Re: SSD

              Posté par  . Évalué à 4.

              Merci du lien, je ne savais pas qu'il pensait ça.

              D'un coté, il n'a pas complètement tort, ça permet d'abstraire les différences du hard, et de mieux optimiser le wear-leveling en fonction du matos particulier, même si je trouve sa comparaison avec la DRAM un peu foireuse, vu que ce que fait le contrôleur de la DRAM est très basique par rapport à ce que doit faire le contrôleur de la NAND.

              Mais bon, dire qu'on devrait plutôt ne pas acheter le mauvais matos, c'est facile à dire mais pas à faire : en gros, on doit éviter _toutes_ les cartes SD/CF/... qui ont toutes du wear-leveling pourri, et quasi tous les SSD saufs peut-être ceux d'Intel. Ça limite quand même beaucoup le choix ...

              Sinon, moi la chose qui me plaisait dans le "raw access" à la flash, c'est le coté on est libre de wear-leveler comme on veut.

  • # Reiserfs

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

    Serait-ce un concurrent sérieux de Reiserfs ? http://en.wikipedia.org/wiki/Namesys
    On retrouve par exemple dans Btrfs une gestion performante des petits fichiers et d'autres caractéristiques de Reiserfs. Actuellement, reiserfs est mon système de fichier préféré mais au vu des caractéristiques de btrfs, il se pourrait bien que je change ma préférence.

    Il semble que Reiser4 n'évolue plus vraiment depuis l'incarcération de Hans Reiser. C'est dommage car il y a dans Reiser4 des fonctions vraiment novatrices. Voir http://web.archive.org/web/20071023172417/http://www.namesys(...) . Pourtant http://lkml.org/lkml/2008/4/18/390 annonce en avril 2008 sa prise en compte par le kernel.

    La page listant les FS de Linux ne semble pas très à jour : http://www.linux.org/lessons/advanced/x1254.html

    • [^] # Re: Reiserfs

      Posté par  . Évalué à -1.

      euh OMG, j'étais pas au courant qu'il avait tué son ex-femme :| ...

      • [^] # Re: Reiserfs

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

        J'ai une photo de Hans Reiser sur http://pjarillon.free.fr/docs/la_bande_des_rmll2000.jpg
        Il avait passé tout son temps avec David Axmark à ses côtés sur la photo. Ils avaient beaucoup discuté des analogies entre la gestion des transactions des bases de données et la journalisation des FS.
        Je crois qu'il en est ressorti quelques progrès de part et d'autre.

        Reconnaissez-vous les autres personnes de la photo ?

      • [^] # Re: Reiserfs

        Posté par  . Évalué à -4.

        Ben c'est pas sûr il me semble, car il n'ont pas retrouvé sa femme.

        • [^] # Re: Reiserfs

          Posté par  . Évalué à 8.

          Si, ça a été discuté ici sur d'autres journaux et dépêche. Il a mené la police au corps pour pouvoir discuter une réduction de peine.

          The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

        • [^] # Re: Reiserfs

          Posté par  . Évalué à -1.

          Ah si... c'est dans l'article sur wikipedia.

    • [^] # Re: Reiserfs

      Posté par  . Évalué à 10.

      > Serait-ce un concurrent sérieux de Reiserfs ?

      Oui, et de loin franchement.
      Ses fonctionnalités sont déjà largement en avance par rapport à celles de reiserfs (et reprennent comme tu le signale les bonnes propriétés de celui-ci).

      Le plus important (à mes yeux, concernant un système de fichier, et en comparaison avec reiserfs) est qu'il promet d'être très activement maintenu, suscitant l'intérêt vif et la participation de développeurs critiques chez IBM, Red Hat, SUSE, Oracle, Intel. Cette diversité est prometteuse, car elle signifie que bientôt chacune de ces sociétés sera capable de gérer les bugs rencontrés par ses clients, donc en mesure de proposer et supporter officiellement ce système de fichiers, de l'affiner pour ses workloads spécifiques, etc. Par contraste, reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus, et il n'est tout simplement pas supporté par Red Hat (autrement dit : peu de chances d'améliorations fonctionelles, désormais, à la différence de ext4, XFS et btrfs).

      Une fonctionnalité bluffante pas décrite dans la dépêche, et pas faisable avec les outils actuels (LVM) : btrfs permet de faire des snapshots d'un répertoire quelconque du système de fichier (par ex. juste le /etc). D'autre part, il n'est pas nécessaire de réserver de l'espace disque dès le départ pour pouvoir faire ses snapshots (comme avec LVM). Ce sont de petits détails, mais il y en a beaucoup comme ça, et ils chacun peu, je pense, changer la vie des sysadmins :).

      Pour répondre à la question de Michel plus haut :
      > Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?

      Pour le moment btrfs ne fait pas grand chose de spécifique pour les SSD. En pratique : la routine de recherche permettant de trouver de l'espace libre et utilisable parmi les extents alloués dispose d'un raccourcis/court-circuit dans le cas du SSD.

      Mais il est prévu d'essayer de tirer le meilleur partis, de façon spécifique, des SSD, c'est d'ailleurs pour ça qu'une option de montage spécifique "ssd" est déjà intégrée.

      XFS (depuis peu, et de façon encore expérimentale) et btrfs intègrent des fonctionnalités de gestion des périphériques multiples (normalement dévolues aux couches MD et LVM du noyau) précisément pour se permettre ce genre d'optimisations : en connaissant précisément la couche physique (le matériel sous-jacent), ils pourront décider au mieux de l'agencement des données. Par exemple, dans un aggrégat de disques durs et de SSD : placer les métadonnées (nécessitant beaucoup d'accès aléatoires) sur le SSD et les données dont l'accès est plus séquentiel sur disque dur, ou encore (et parce que, pour des raisons de fiabilité, btrfs permet de dupliquer les métadonnées critiques) savoir comment répartir les diverses copies sur des disques effectivement physiquement différents est difficile lorsque cette information est masquée par l'agrégation LVM ou MD.

      Et aussi : btrfs (comme ZFS en fait) peut (si monté en conséquence) s'assurer de l'intégrité des données à l'aide de checksums (pour le moment, uniquement des crc32). S'il a un accès direct aux disques physiques (direct = pas déjà agrégé / masqué par une couche raid sous-jacente), il peux décider de chercher une copie en bon état du bloc concerné, puis la dupliquer de nouveau sur le disque où la copie était mauvaise (mais dans un autre bloc), voir prendre des décisions pertinentes au sujet des blocs contigus ou du disque lui-même. Un gestionnaire RAID classique, lui, ne pouvant pas accéder aux informations du fs, se contentera de mettre le disque entier offline dès qu'il détectera le problème. C'est une problématique importante, justement, pour les SSD (dont certains blocs peuvent "vieillir" sans que l'ensemble du périphérique soit à jetter), et en fait, avec les gros disques modernes (le risque d'une panne globale du disque est aussi grand qu'auparavant, mais le risque d'avoir un ou deux blocs défectueux augmente au fur et à mesure que les disques grossissent en capacité).

      Ou encore : sur un système RAID classique (logiciel avec mdadm ou lvm, ou matériel), la couche RAID permet d'avoir une seule taille de stripe, définie à la construction de l'agrégat. Ce choix n'est pas optimal pour tout les cas, même lorsque le système de fichier est proprement aligné sur les stripes (par ex. avec l'option "stride" d'ext3/ext4) : les lectures/écritures séquentielles de gros fichiers bénéficient de larges stripes, tandis que les petites écritures (métadonnées, par ex.) bénéficient de petites stripes (sans quoi, les écritures successives seront mal réparties sur les divers disques physiques de l'array). Or le système de fichier dispose de ses informations (taille probable des lectures/écritures) ; il est donc en mesure de prendre de très bonnes décisions en allouant des stripes de taille dynamique selon ses besoins spécifiques.

      Je signale au passage que sur ce point (la fameuse "rampant layering violation") cette dépêche est fausse.

      Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur Wikipédia, qui se base sur des informations juste mais datées. En pratique, Chris Mason avait l'intention d'essayer de faire un fs qui communique et délègue aux couches pertinentes (d'où le texte dans l'article de WP), mais s'est aperçu ensuite qu'il devait gérer l'essentiel dans le système de fichiers lui-même pour pouvoir exploiter de façon optimale les périphériques multiples (cf. plus haut), les snapshots, etc.

      En somme, l'intention de départ était bien, effectivement, de ne pas "violer" les divers "block layers" du noyau, mais ce qui s'est réellement passé c'est que la mentalité des développeurs Linux a globalement évolué sur ce point, et que ce type de "violations" est désormais considéré comme légitime (dans une certaine mesure). Le paradigme a simplement changé, les développeurs Linux ne sont pas obtus.

      Voyez cette paire de réponse de Christophe Hellwig (développeur de XFS) et Chris Mason (développeur de btrfs) à Andrew Morton qui s'interrogeait récemment sur cette question de "layering violation" :
      http://thread.gmane.org/gmane.comp.file-systems.btrfs/1601/f(...)
      http://article.gmane.org/gmane.comp.file-systems.btrfs/1764

      • [^] # Re: Reiserfs

        Posté par  . Évalué à 2.

        Je me trompe ou bien il existe une analogie entre les disques SSD et les cartes CompactFlash et tout ce qui y est similaire? En d'autres termes, si Btrfs arrive à maturité, pourra-t'on aussi s'en servir comme remplaçant de JFFS/CFFS?

      • [^] # Re: Reiserfs

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

        > btrfs permet de faire des snapshots d'un répertoire quelconque du
        > système de fichier

        Cette fonctionalité est géniale car elle va permette de faire des sauvegardes à cout CPU quasi nul. Il va être très facile de programmer des retours arrières pour tout un tas d'opération (upgrade de système par exemple). Cette fonctionalité va de paire avec le snashot de snapshot. Les possibilités sont énormes.

        > Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur
        > Wikipédia

        Je ne sais pas si Patrick a écrit la version anglaise sur Wikipedia. Je suis partis sur cette version la car je savais que pas mal de personne sauterais sur la version Française de wikpedia. Ainsi le débat n'est en que plus animé, la version anglaise étant assez différente de la version française.

        Au niveau de la séparation avec la couche LVM et le fait que cette séparation ne soit pas effective, je trouve cela dommage. J'aurais préféré que le système LVM et le device-mapper soient étendus afin de pouvoir répondre aux questions existentielles des systèmes de fichier.

        Sinon, je n'y connais rien en système de fichier, j'essaye juste d'être un utilisateur avertis ;-)

        Sinon, il y a une "extension" a BrtFS qui me semble aussi intéressante : CRFS (Coherent Remote File System), Il s'agit en fait d'une couche réseau pour accéder au système de fichier à distance. A suivre... car je ne sais pas ce que cela apporte par rapport a du NFSv4 ou du parrallèle NFS. En tout cas, il est bien préciser que CRFS se base sur les fonctionalités de BtrFS.

        • [^] # Re: Reiserfs

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

          >>> Je ne sais pas si Patrick a écrit la version anglaise sur Wikipedia.

          Non pas du tout. J'ai simplement posté une partie de ma news LinuxFR dans l'article français : http://fr.wikipedia.org/wiki/Discuter:Btrfs

        • [^] # Re: Reiserfs

          Posté par  . Évalué à 4.

          "Cette fonctionalité est géniale car elle va permette de faire des sauvegardes à cout CPU quasi nul. Il va être très facile de programmer des retours arrières pour tout un tas d'opération (upgrade de système par exemple). Cette fonctionalité va de paire avec le snashot de snapshot. Les possibilités sont énormes."
          On pourrait peut-être même imaginer des VCS reposant sur les snapchsots, non ?
          Bon, je sais que cela induirait forcément une dépendance forte entre le soft et le FS, ce qui n'est sans doute pas recommandé... Mais l'idée ne tiendrait-elle pas la route ?
          (c'est une vraie question).

          • [^] # Re: Reiserfs

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

            Ben tu te réponds en fait.

            Un des principes de bases d'un VCS est de pouvoir "tourner" sur plusieurs platformes donc ne relier le soft qu'a un FS sur un OS ce n'est pas très interssant (même si on peut imaginer une couche d'abstraction pour ZFS).
            Sur un système centralisé (comme subversion) ca peut être utilisé sur le serveur mais il peut y avoir un risque en terme de sauvegarde. Il faut être certain que l'on pourra toujours acceder aux données dans 10,15 ou 20 ans. Je pense que ce risque est plus fort si on dépend d'un FS que d'un format de fichier indépendant.

            La ou c'est plus interessant, comme indiqué plus haut, c'est la possibilité pour tout un tas de soft de proposer, facilement ,des fonctionnalités transactionnelles sans dépendre d'un DB.

        • [^] # Re: Reiserfs

          Posté par  . Évalué à 2.

          Concernant Wikipedia, je me suis permis d'apporter quelques modifications (principalement snapshot-->instantanés et des corrections de grammaire).

          Il reste un truc pas très joli: "Si des données sont écrites sur un bloc mémoire alors ce dernier sera copié à un autre endroit du système de fichiers et les nouvelles données seront enregistrées sur la copie au lieu de l'être sur l'original."
          Je n'ai pas trouvé comment remanier la phrase.

      • [^] # Re: Reiserfs

        Posté par  . Évalué à 7.

        > reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus,
        Rhoo, il abuse, franchement... Abandonner son FS comme ça...

        • [^] # Re: Reiserfs

          Posté par  . Évalué à 5.

          Ça fait des années que Reiser ne participait plus à ReiserFS, quand il a commencé Reiser4 (2004 ?) il a arreté le dev ReiserFS. C'est donc les distributions qui ont pris le relai (principalement SUSE et Mandriva, Chris Mason faisait partir de l'équipe de chez SUSE qui maintenait ReiserFS).

  • # Ext4 ou Brtfs ?

    Posté par  . Évalué à 4.

    Maintenant la question qui se pose est: Ext4 ou Brtfs ?

    Parce qu'avec toutes ces fonctionnalités Brtfs à l'air plus intéressant que Ext4.

    Et aussi, est-ce que Ext4 n'est-il pas voué à être un fs de remplacement que peu de personne auront utilisé ?

    • [^] # Re: Ext4 ou Brtfs ?

      Posté par  . Évalué à 8.

      Ext4 est stable;
      Btrfs est encore très loin de l'être !

      Il faut voir Btrfs comme le futur successeur de Ext4, je ne lis pas ça dans une boule de cristal, c'est Theodore T'so, le développeur principal de Ext4 qui le dit :-) !

      • [^] # Re: Ext4 ou Brtfs ?

        Posté par  . Évalué à 4.

        Stable? Quelle distrib propose ext4 en stable? J'ai installé dans Virtualbox Mandriva2009 et Suse11, et en aucun cas il n'est proposé de formater en ext4.

        Ext4 est-il vraiment recommandé en production?
        En fait, on en parle peu. Peut-être qu'il est stable.

        • [^] # Re: Ext4 ou Brtfs ?

          Posté par  . Évalué à 3.

          Ext4 n'est pas encore recommandé en production, il sera recommandable d'ici une ou deux versions du noyau.

        • [^] # Re: Ext4 ou Brtfs ?

          Posté par  . Évalué à 2.

          On a seulement retiré le tag en cours de développement de ext4 pour le noyau 2.6.28, openSUSE 11.1 est sortie avec 2.6.27 et mandriva 2009 est en développement donc ils n'ont peut-être pas encore inclus la fonctionnalité.

          « 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

    • [^] # Re: Ext4 ou Brtfs ?

      Posté par  . Évalué à 7.

      Il n'y a pas vraiment de concurrence : Ext4 est une évolution d'Ext3 destiné à être employé jusqu'à ce que Btrfs soit pleinement finalisé et opérationnel.

      Ted Tso, développeur principal d'Ext4, et d'autres spécialistes des systèmes de fichiers se sont mis d'accord lors du dernier workshop dédié à ce sujet pour adouber Btrfs « NGFS » : Next-Generation File System, c'est à dire le principal futur système de fichier moderne pour Linux.

      Ted Tso signale également qu'il est pleinement pour l'intégration de Btrfs dans le noyau, donc a priori il ne me semble pas du tout y avoir de rivalité entre lui et son auteur, Chris Mason.

      Source : http://thread.gmane.org/gmane.linux.file-systems/26246/focus(...)

    • [^] # Re: Ext4 ou Brtfs ?

      Posté par  . Évalué à 2.

      > Maintenant la question qui se pose est: Ext4 ou Brtfs ?

      Comme le disent d'autres commentaires, ça sera Ext4 ET Btrfs. Comme ça a été Ext2 ET Ext3, comme ça sera et c'est maintenant Ext3 ET Ext4.
      De nombreux mois, et très probablement des années, vont passer avant que Btrfs soit au point. Ext4 est déjà au point (ou plus très loins). Btrfs est le remplaçant à venir de Ext4. Ext4 roxe, donc Btrfs sortira (en 1.0) lorsqu'il roxera, qu'il n'y aura pas de régression par rapport à Ext4, qu'il sera aussi fiable et apportera son petit plus par rapport à Ext4. BtrFS a quasiment la garantit d'y arriver car nombre de développeurs Ext vont bosser sur BtrFS. Donc Ext4 va stagner et BtrFS progresser.

      Je vais en froisser quelqu'uns, mais Ext* a été (et est toujours) LE système de fichier de Linux. BtrFS sera LE système de fichier de Linux.

      En passant, Ext4 est dans F10 (faut ajouter "ext4" lors du boot de l'installation). Je l'utilise, rien à dire sinon que ça marche. Il sera peut-être par défaut pour F11. Il sera très probablement par défaut pour RHEL 6. Novell a abondonné Reiser(FS|4) pour Ext*. Ext4 sera par défaut dans la distribution entreprise de Novell. Ext4 répond aux besoins actuels. Ça donne du temps à BtrFS. Pas pour flémarder, mais pour innover.

  • # Gestion de la défragmentation lors de l'utilisation en tâche de fond

    Posté par  . Évalué à 2.

    Je suis un novice en système de fichier, mais il me semblait que Linux favorisait des systèmes de fichiers où la défragmentation était inutile...
    Quelqu'un pourrait éclairer ma lanterne ?

  • # fix typo

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

    Il y a une faute de typo dans les noms des 3 premiers liens

    s/Brtfs/Btrfs/g

  • # Pendant ce temps là, en parlant de système de fichiers...

    Posté par  . Évalué à 10.

    Le nouveau format des cartes SD, le format SDXC a été annoncé :
    http://www.zdnet.fr/actualites/informatique/0,39040745,39386(...)

    Et encore une fois, il utilise un système de fichier d'avenir (exFat), ouvert au possible, sans royalties ni brevet d'une petite PME de seattle et actuellement lisible qu'avec Vista Sp1 (exit actuellement tous les autres).
    http://fr.wikipedia.org/wiki/ExFAT

    Encore un choix censé!!

  • # LVM Obsolète ?

    Posté par  . Évalué à 2.

    Bonjour à tous,

    Je me pose une question et la news (de qualité :-) ) n'est pas très claire sur le sujet :
    Est-ce que Btrfs va rendre obsolète l'utilisation de softs comme LVM comme c'est le cas avec ZFS ?

    En particulier est-ce que l'on pourra redimensionner (agrandir ET rétrécir) une partition Btrfs sans soucis et se passer de LVM pour ce genre de tâche !

    Merci de vos éclaircissement !

    • [^] # Re: LVM Obsolète ?

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

      Note qu'avec ZFS, tu ne peux pas agrandir ou rétrécir un volume puisqu'un volume n'a pas de taille. Tu choisis juste sa réservation et/ou son quota (bon d'accord je sais ça revient au même).

      • [^] # Re: LVM Obsolète ?

        Posté par  . Évalué à 2.

        il faut préciser : on peut agrandir un zpool (ajout de devices). tous les dataset à l'intérieur de ce pool profiterons du nouveau device et pourront voir leur taille augmenter (à moins qu'un quota ait été mis en place)

        Quand à la réduction d'un zpool (enlever un device du zpool), ce n'est effectivement pas possible, pour le moment....

    • [^] # Re: LVM Obsolète ?

      Posté par  . Évalué à 5.

      Examples

      Suppose your Mountpoint is /mnt:

      add 2GB to the FS

      btrfsctl -r +2g /mnt

      shrink the FS by 4GB

      btrfsctl -r -4g /mnt

      Explicitly set the FS size

      btrfsctl -r 20g /mnt

      Use 'max' to grow the FS to the limit of the device

      btrfsctl -r max /mnt


      Citation de http://btrfs.wiki.kernel.org/index.php/Btrfsctl

      • [^] # Re: LVM Obsolète ?

        Posté par  . Évalué à 3.

        À part la réduction à chaud, Ext3 (et 4) peut déjà faire tout ça.

        Ce que chicha demande, c'est si Btrfs peut remplacer LVM, et donc offrir toutes les fonctionnalités de celui-ci, comme l'aggrégation de disques (avec possibilité de stripping) et le découpage en volumes logiques.

        Pour l'instant ce n'est pas le cas, mais sait-on jamais, ça sera peut-être dans la version 1.0, pourquoi pas ?

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

        • [^] # Re: LVM Obsolète ?

          Posté par  . Évalué à 1.

          Ah ? j'avais compris qu'il demandait si on pouvait redimenssionner à chaud (et oui, bien sûr, ext3 peut être agrandi à chaud depuis quelques temps).

          Pour ce qui est de l'agrégation de disques et du stripping, voyez (pas tout à fait à jour d'ailleurs) :
          http://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mult(...)

          ça me semble déjà pas mal, pour un début :)

          • [^] # Re: LVM Obsolète ?

            Posté par  . Évalué à 2.

            Zut, j'ai omis sa deuxième question, à laquelle tu répondais.

            Enfin, ce lien est très intéressant, ça veut dire que Btrfs sera plutôt équivalent à ZFS qu'Ext. Personnellement, je trouve un peu dommage d'outrepasser le device mapper (qui devait être me semble-t-il l'unique point d'accès au stockage dans le noyau) et d'accéder directement aux disques pour toutes ses manipulations internes.

            Certes, ça doit énormément simplifier l'administration (par exemple, pas de casse-tête lors de la réduction d'un fs, où une opération par couche est nécessaire, tout en tenant compte des écarts...), mais j'aime bien l'idée actuelle des couches séparées, qui permet de faire tout et n'importe quoi (chaque élément pouvant contenir n'importe quel élément).

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

            • [^] # Re: LVM Obsolète ?

              Posté par  . Évalué à 4.

              ah ce que j'ai cru comprendre, si tu veux utiliser LVM et utiliser des couches séparé tu peux. Par contre tu pourras pas demander au FS (donc dans les couches hautes) de réparer les problèmes des couches basses (vu que les couches sont séparé il n'en a pas connaissance).

              Donc tu peux faire tout et n'importe quoi, mais ca te rajoutera de l'administration.

              avec zfs (sous linux) c'est la meme chose, si tu veux créer un device sur un loopback par exemple, tu peux sans problème. Par contre il pourrait pas utiliser (de façon optimale tout du moins) ses algorithmes de réplication et de choix des blocs itou.

          • [^] # Re: LVM Obsolète ?

            Posté par  . Évalué à 1.

            Je vous remercie à tous les deux pour vos réponses.

            herodiade : c'est exactement ce que je voulais savoir. Je n'utilise LVM que pour pouvoir agrandir et réduire des partitions ext3 sans souci et jouer avec mes partitions sur un seul disque seulement (j'ai deux disques mais un groupe par disque).

            Guillaume : tu réduis souvent des ext3 en dehors d'un LVM ? ça se passe bien ? si oui alors dans mon cas LVM ne sert à rien ?

            • [^] # Re: LVM Obsolète ?

              Posté par  . Évalué à 3.

              tu réduis souvent des ext3 en dehors d'un LVM ? ça se passe bien ? si oui alors dans mon cas LVM ne sert à rien ?

              Non, j'utilise LVM+ext3 pour les mêmes raisons que toi, à savoir réduire des fs et réallouer l'espace libre à d'autres fs, ce qui n'est pas possible sans un outil de volumes logiques (ou alors je ne sais pas comment).

              J'ai déjà pu expérimenter la réduction de fs ext3 sur des partitions classiques : ça se passe bien, mais j'ai toujours une certaine appréhension. En effet, une fois que tu as réduit le fs, la méthode consiste ensuite à supprimer la partition puis la recréer avec une taille plus petite. Tu comprendras que je ne suis pas fan du fait de supprimer une partition... Et en plus, pour utiliser l'espace gagné, tu dois créer une nouvelle partition.

              Finalement, la solution LVM reste la plus souple et a fait ses preuves, autant y rester pour l'instant.

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

              • [^] # Re: LVM Obsolète ?

                Posté par  . Évalué à 2.

                Je te remercie pour le partage de ton expérience.
                Nous avons les mêmes besoins et nous utilisons LVM de la même façon pour y répondre :-)

                Maintenant c'est toujours pas super clair pour moi si oui ou non je vais pouvoir me passer de LVM pour gérer mon disque. J'ai peur que non :

                Cas LVM :
                Si j'ai bien compris et en schématisant : LVM permet de gérer un pool de blocs et d'allouer tel ou tel quantité de blocs a tel ou tel volume logique lui-même associé à une partition. Un des intérêts c'est que l'on peut réorganiser tout ça sans perte de données.

                Cas Btrfs :
                Dans le cas ou j'aurais un disque avec 3 partitions Btrfs sans LVM.
                Est-ce que je pourrais réduire 2 d'entre elles et en créer facilement une 4ième avec l'espace libéré ? Est-ce qu'on pourra créer une partition avec des blocs libérés un peu n'importe ou sur le disque ? Je doute fort non ?

                Votre avis m'intéresse !
                Merci beaucoup :-)

                • [^] # Re: LVM Obsolète ?

                  Posté par  . Évalué à 3.

                  je pense, en tout cas avec une logique pure "Zfs" , que tu ne devrais pas avoir à "réduire" et "augmenter" la taille du pool.
                  Tu attribue des disques à ton Zfs, et _dans_ ton fs, tu attribue ce que tu veux (quota ET réservation d'espace!) pour les fs/répertoire que tu as crée.
                  La facilité d'administration des fs (qui s'utilisent comme des répertoires) permet ça.

                  (bon par contre ça oblige l'utilisation de zfs, donc peut pas utiliser cette place pour quelque chose qui comprend pas zfs).

                  J'ai vu des gens s'extasier devant des portages iscsi et une solution propriétaire très cher qui permettait de "réserver" de l'espace disque et donc d'exporter des disques virtuels (par dessus un SAN) par iscsi qui pouvaient être modifié dynamiquement en taille.
                  Et quand je leur ais dit que je pouvais le faire pour juste le cout du hardware avec un solaris et zfs ils m'ont pas cru XD.

        • [^] # Re: LVM Obsolète ?

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

          A priori si j'ai bien compris les messages précédents, il me semble que brtfs n'ait pas pris le même chemins que ZFS. Ils ne cherchent pas à réécrive des fonctionnalités disponibles sur une couche plus basse (LVM, MD-RAID) mais ils en tirent parti pour optimiser les fonctions FS comme la répartition des metadata sur plusieurs disques, etc.

          Vraiment très intéressant cet approche que je reprochais à ZFS. J'applaudis des 2 mains.

          • [^] # Re: LVM Obsolète ?

            Posté par  . Évalué à 5.

            Je suis allé voir la FAQ du projet :

            Does the Btrfs multi-device support make it a "rampant layering violation"?

            Yes and no. Device management is a complex subject, and there are many different opinions about the best way to do it. Internally, the Btrfs code separates out components that deal with device management and maintains its own layers for them. The vast majority of filesystem metadata has no idea there are multiple devices involved.

            Many advanced features such as checking alternate mirrors for good copies of a corrupted block are meant to be used with RAID implementations below the FS.

            Les devs sont donc conscients de l'importance de cette hierarchie des couches, mais certaines optimisations nécessitent des fonctions plus bas niveau que ne le permet celle-ci. Donc pour rester cohérent, Btrfs est développé en séparant le FS pur de la gestion matérielle, ce qui permet à l'utilisateur soit de respecter cette convention, soit de l'ignorer s'il veut profiter d'une implémentation optimale.

            Autrement dit, cette approche me paraît très ouverte et pragmatique, bien plus que ton commentaire ne l'affirme. Je crois qu'on peut s'attendre à un résultat très impressionnant.

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

  • # Et Tux3 ?

    Posté par  . Évalué à 6.

    Pardonnez-moi de diverger, siouplè, mais il y a dans cette dépêche quelques informations qui me font penser à tux3.

    Je me suis intéressé à ce FS à la fin de l'année dernière, par curiosité et parce que le nom est amusant. Au début de l'année j'ai enfin pu compiler un module kernel à partir des sources récupérées sur le dépôt mercurial et copier quelques fichiers sur une partition tux3 (c'était le seul objectif fixé). La doc que j'ai trouvée était très technique et volait bien au dessus des mes simples connaissances en système de fichiers.

    Pensez-vous que tux3 soit un système de fichiers qui a des chances de percer et de finir un jour à côté de btrfs, pas forcément au même niveau ? Ou alors quelques petites informations accessibles sur tux3 afin de comprendre un peu plus l'engin et, par exemple, pouvoir le comparer à btrfs si il y a moyen de faire.

    Pour l'instant ext3 me convient parfaitement, c'est seulement au titre de ma curiosité maladive que je me permets de demander. :)

    The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

  • # Snapshot ...

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

    Pour l'utilisation bureautique (plutôt que serveur), est-ce qu'il serait possible/envisageable de disposer d'un système de snapshot dont la portée est limitée à un fichier ou un répertoire donné ?

    À mon avis ce serait vraiment une fonctionnalité intéressante de pouvoir faire, dans mon gestionnaire de fichier, click droit -> créer un point de restauration ; ou encore de choisir la version actuelle de travail en un click.

    Certes ça n'aurait pas la vocation à concurrencer Git (notamment du fait de la duplication totale du fichier à la création du snapshot), mais pour un utilisateur "lambda" (comme moi) ce serait une fonctionnalité intéressante.

    (en fait peut être est-ce déjà dans la roadmap de btrfs, je n'ai pas vérifié l'info...)

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Snapshot ...

      Posté par  . Évalué à 4.

      Certes ça n'aurait pas la vocation à concurrencer Git (notamment du fait de la duplication totale du fichier à la création du snapshot)

      Git fait une duplication totale des fichiers. Tant qu'il n'y a pas eu de repack, chaque version de chaque fichier à sa propre copie sur le disque.

      • [^] # Re: Snapshot ...

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

        Ha, j'ignorais (j'en étais encore à diff). Merci de cette mise au point.

        Adhérer à l'April, ça vous tente ?

    • [^] # Re: Snapshot ...

      Posté par  . Évalué à 3.

      Les snapshots par répertoires ne sont pas encore tout à fait là, mais sont au planning . Ils étaient prévus pour fin mars 2008[1], mais Mason à préféré travailler en priorité sur les éléments de bases permettant l'intégration mainline[2] (comme la capacité de gérer proprement les partitions saturées).

      Cela étant, les snapshots (de tout le root fs) sont d'ors et déjà peu couteux (COW oblige).

      [1] C'est indiqué, par exemple, dans la timeline de btrfs, ici: http://oss.oracle.com/projects/btrfs/dist/documentation/todo(...)
      Le site oss.oracle.com est entièrement down pour le moment, désolé, voici une version en cache :
      http://209.85.129.132/search?q=cache:j0rkDJXeAQMJ:oss.oracle(...)
      Ou si tu préfère, voici un article qui cite cette timeline (dernier paragraphe) : http://lwn.net/Articles/265257/

      [2] Ce qu'en dit Chris Mason directement (là aussi, l'archive de la m-l est sur oss.oracle.com ...) :
      http://209.85.129.132/search?q=cache:GBzfRbsdgtAJ:oss.oracle(...)

      • [^] # Re: Snapshot ...

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

        > Le site oss.oracle.com est entièrement down pour le moment, désolé, voici une version
        > en cache :

        Pas de pot, je fais une dépêche la dessus et leur site est HS depuis déjà un bout de temps. Idem tout à l'heure, je n'ai pas pu mettre la référence de la partie réseau associé BtrFS.

        A mon avis, on est trop nombreux à vouloir y aller ! DLFP a trop de succés !

    • [^] # Re: Snapshot ...

      Posté par  . Évalué à 3.

      "notamment du fait de la duplication totale du fichier à la création du snapshot"
      Non justement, le fichier n'est pas entièrement recopié lors de la création du snapshot, grâce au "copy-on-write", qui crée de nouveaux blocs dès qu'un bloc snapshoté est modifié (donc tous les blocs identiques entre le snapshot et la version courante, sont en fait communs).

      • [^] # Re: Snapshot ...

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

        Et bah justement, au moment ou tu forke un fichier, dès le premier enregistrement il y aura bien duplication des données. Je ne fait pas ici allusion au snapshot d'une partition entière (certes dans le cas du snapshot d'un répertoire ta remarque se tient).

        Adhérer à l'April, ça vous tente ?

        • [^] # Re: Snapshot ...

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

          Pas forcément. comme BtrFS a un notion du bloc (les autres système de fichier aussi), alors il ne copiera que les blocks modifiés mais pas l'ensemble du fichier.

          C'est exactement ce que fait LVM lors d'un snapshot.

  • # Fin des ajouts dans le 2.6.29

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

    C'est finit, le 2.6.29 basule en mode deboguage, Linus a annoncé cela.

    http://lwn.net/Articles/314471/

    Au bilan, les trois grands apport de cette version seront

    * squashfs : un système de fichier compressé en lecture seule

    * Btrfs (en mode développement, pas pour l'utilisateur lambda)

    * Les "modes settings" pour les cartes graphiques Intel (chose que faisait avant X-Window et qui bascule petit à petit dans le noyau).

  • # Granularité du COW ?

    Posté par  . Évalué à 3.

    Le COW est-il au niveau du fichier ou un à un niveau plus petit ?

    Dit autrement, lorsqu'une portion d'un fichier est modifiée par COW, est-ce l'ensemble du fichier qui est dupliqué ou seulement la partie modifiée ?

    Je me pose la question de le cadre de "gros" fichiers et plus particulièrement pour des images disques de machines virtuelles où les snapshot BTRFS pourraient se substituer aux snapshot de VM.

    • [^] # Re: Granularité du COW ?

      Posté par  . Évalué à 4.

      De mémoire, pour ZFS, le Copy On Write (COW) se fait au niveau bloc, donc seuls les blocs modifiés sont dupliqués. Donc oui, en cas de gros fichiers faiblement modifiés, c'est 'efficient'.

      Il me semble que c'est aussi le cas pour btrfs, mais je n'ai pas encore bien digéré l'explication du design, à lire pour les mordus de FS: http://btrfs.wiki.kernel.org/index.php/Btrfs_design

      • [^] # Re: Granularité du COW ?

        Posté par  . Évalué à 3.

        Il y a un autre souci avec le COW, qui est rarement évoqué et qui pourtant va exclure provisoirement ces systèmes de fichiers de certaines applications.
        Par nature le copy-on-write defait toute stratégie d'effacement sécurisé puisque les blocs ne sont pas écrasés mais réécrits à côté. L'attitude adoptée par ZFS comme Btrfs pour l'instant, c'est "on l'a mis dans la roadmap" ; Chris Mason a déjà dit que ça serait pas dans la version 1.0 de Btrfs et que la solution qui avait sa faveur était de crypter les blocs, ainsi l'effacement sécurisé revient à jeter la clef. Cette solution pose quand même des petits problèmes, en particulier si on sait pas au départ quels fichiers devront faire l'objet d'un effacement sécurisé, il faut tout crypter - en plus pour que ça soit crédible il faut crypter sérieusement, et ça ça a un coût.

        • [^] # Re: Granularité du COW ?

          Posté par  . Évalué à 1.

          Oui, mais pour pouvoir jeter la clef, il ne faut pas qu'elle ait été stoquée sur le FS ! Ou alors il faut chiffrer cette clef pour pouvoir jeter la nouvelle clef de chiffrement pour pouvoir oublier la première clef...

          StackOverflowError at Brain (unknown location)

          (oui, je sais, mon cerveau a une pile *très* limitée...)

        • [^] # Re: Granularité du COW ?

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

          > Par nature le copy-on-write defait toute stratégie d'effacement sécurisé
          > puisque les blocs ne sont pas écrasés mais réécrits à côté.

          Je ne vois pas ou est le problème...

          Pour vraiment effacer les données, il faut ré-écrire dessus un certain nombre de fois et non une seule fois.

          Rien n'empêche d'écrire le fihcier n+1 sur l'ancien fichier n.

          Mieux encore, rien n'empêche d'avoir une option de montage, du style 'secure-delete' qui écrirait dans un journal tous les block qui ne servent plus et qu'un processus parallèle de BtrFS s'occuperait en tâche de fond d'effacer entre 4 et 7 fois avec des données aléatoires.

          Bref, je ne vois pas ou est la sécurité de ré-écrire au même endroit.

          • [^] # Re: Granularité du COW ?

            Posté par  . Évalué à 2.

            Heu, un secteur effacé une fois n'est plus lisible par le disque. La méthode que tu préconise (écrire plusieurs fois) n'est valable que pour les gens qui sont prêts à démonter le disque et y aller avec du matos très spécifique et très cher. La sécurité c'est une question de moyens qu'on y met, et il me semble que le but ici n'est "que" de se prémunir du cas où quelqu'un va "simplement" vouloir trouver des données non-écrasées sur le disque ...

            • [^] # Re: Granularité du COW ?

              Posté par  . Évalué à 2.

              de toute façon, ceux qui veulent vraiment conserver leur données secrete démonte le dd, le démagnétisent, le brule, puis en font de la charpie (qui a parlé de la CIA ? Xd).

            • [^] # Re: Granularité du COW ?

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

              Rien n'empêche de ne faire qu'une écriture. Option 'secure-delete=1' par exemple. Et puis, il peut mettre des zéro ou des chiffres aléatoire... Encore une fois, je pense que déléguer cette tâche a un processus parallèle asynchrone me semble une bonne idée.

              • [^] # Re: Granularité du COW ?

                Posté par  . Évalué à 4.

                Le problème n'est pas la méthode de réécriture pour rendre illisible les données initiales ; il en existe plusieurs et les programmes qui font se genre de chose laissent souvent le choix à l'utilisateur du nombre de passes, etc.
                Le problème est que ça marche bien avec un système de fichier du type ext3 par exemple par que si tu lui dit écrase le contenu du bloc N avec ce pattern, il va effectivement écrire par dessus le bloc N qui sera ensuite illisible, l'implémentation du système de fichier n'a pas à le savoir c'est en dehors de son domaine.
                Quand on utilise du COW, l'implémentation du système de fichier va écrire un nouveau bloc autre part sur le disque (ou plusieurs éventuellement dans un scénario RAID-Z et co) et marquer simplement l'ancien comme libre à la fin. Donc le secure delete a besoin d'un support au niveau du fs pour fonctionner (ce qui est un problème différent de la manière dont il est exécuté) et actuellement ce support n'existe à ma connaissance pas dans l'implémentation de ZFS, ni dans celle dans Btrfs, il est simplement "envisagé" (comme dans "on y réfléchit"). Pour l'instant le secure delete dans Btrfs ou ZFS, tintin, et il vaut donc mieux le savoir.

                • [^] # Re: Granularité du COW ?

                  Posté par  . Évalué à 1.

                  cela m'étonne quand même que, si la taille d'un fichier n'augmente pas, et qu'il n'est pas "protégé" (cad référencé par un snapshot, clone ou semblable), le fs va copier le bloc autre part, parce que dans ce cas la fragmentation va exploser.

  • # Défragmentation

    Posté par  . Évalué à 1.

    • Gestion de la défragmentation lors de l'utilisation en tâche de fond

    En gros, la fragmentation est comme sous Windows (avec FAT* et NTFS), puisqu'il y a besoin de trouver un moment pour défragmenter ??

    Quelles sont les différences entre la fragmentation des EXT* et de BTRFS ?

    • [^] # Re: Défragmentation

      Posté par  . Évalué à 2.

      EXT et BrtFS fragmentent, c'est normal pour un système si on ne veut pas perdre de place. Le problème de FAT et NTFS est qu'ils ne cherchent pas à éviter la fragmentation, en gros, on commence à mettre le fichier dès qu'on trouve de l'espace entre 2 blocs occupé et tant pis si on doit fragmenter. Tandis que EXT* (et sans doute BrtFS) essaye(nt) de trouver un espace suffisamment gros pour ne pas fragmenter le fichier mais si le fichier est trop gros, il faut le fragmenter. Il est donc tout à fait normal de pouvoir défragmenter sa partition. Par exemple, pour mon /home en ext2, il y a 4,5% de fichiers non-contigus.

      « 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

      • [^] # Re: Défragmentation

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

        A vrai dire je suis d'accord avec toi sur la FATxx mais je pense (je peux me tromper) que NTFS évite également la fragmentation (à l'aide de sa MFT, ...)

        Quelqu'un peut-il confirmer ou infirmer ?

        Peut-être que les systèmes de fichiers Linux sont plus performant néanmoins.

        • [^] # Re: Défragmentation

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

          NTFS fragmente à mort !

          Tu installes un Windows XP sur une partition de 15Go, tu fais les mises à jour et tu regardes la fragmentation, c'est lamentable... pour une machine qui n'a même pas encore servit en production.

Suivre le flux des commentaires

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