btrfs avance à grands pas

Posté par  . Édité par Florent Zara et Nÿco. Modéré par claudex.
Étiquettes :
60
20
fév.
2012
Linux

btrfs, « le petit système de fichiers qui monte », progresse chaque jour, notamment sous les houlettes d'Oracle (qui entend peser de tout son poids pour le faire admettre comme un concurrent sérieux à ZFS) et RedHat. Une petite recherche ciblée sur le net a permis de dénicher quelques nouvelles intéressantes. Chers lecteurs passionnés par les développements dans le monde austère et précautionneux du stockage de nos chères données, la suite de cette dépêche est pour vous !

NdM : merci à AP pour son journal.

ZFS, l'aîné et la source d'inspiration de btrfs, jouit déjà d'une bonne réputation en entreprise. Il n'est pas intégrable nativement au noyau Linux pour des questions d'incompatibilités de licence. Il continue de narguer btrfs avec sa tonne de fonctionnalités mais commence à se faire du mouron quand il examine la feuille de route de son cadet, lequel compte bien le rattraper en terme de possibilités. Citons notamment :

  • Les modes RAID5 et RAID6, apparemment déjà implémentés par des développeurs de chez Intel et qui devraient rencontrer le public dans le noyau 3.4 ou 3.5 ;
  • Le mode « 3 copies » : imaginez un RAID1 sur 3 blocs au lieu de 2 ;
  • La possibilité d'envoi/réception par le réseau des snapshots (comprendre : juste les blocs modifiés) ;
  • Le chiffrement ;
  • Le « scrubbing » automatique en tâche de fond pour régulièrement traquer les corruptions et ventiler uniformément les données entre les disques ;
  • L'optimisation de placement des extents en tenant compte des vitesses des supports de stockage. En très résumé, on placerait les extents les plus fréquemment utilisés sur les supports les plus rapides ;
  • De nouveaux algorithmes de compression, qui se tirent la bourre à qui sera le plus rapide (Snappy, de chez Google, ou LZ4, en plus de zlib et LZO) ;
  • L'arlésienne : enfin un fsck en lecture/écriture ! Oracle met à ce propos une grosse pression sur Chris Mason, son employé et développeur principal sur le projet btrfs ;
  • La déduplication, fréquemment demandée par les utilisateurs, est un projet à moyen terme/en priorité basse. De l'aveu de Chris Mason, il n'est pas trivial à traiter.

Je ne saurais trop vous recommander la récente présentation de btrfs par Avi Miller (un collègue de Chris Mason chez Oracle et co-développeur) lors de la conférence Linux.Conf.Au 2012. C'est tout chaud et les 48 minutes que durent la vidéo sont riches en enseignements. Avec humour et une pointe d'auto-dérision, Avi Miller détaille l'état d'avancement de btrfs ainsi que ses nouveautés qu'on peut attendre à court et moyen terme dans btrfs… J'ai trouvé notamment dans cette vidéo très intéressante la comparaison visuelle (à 34'14") des comportements d'ext4, XFS et btrfs quand on tente de créer énormément de fichiers. Les démonstrations effectuées sont également très parlantes et mettent en avant ce qu'on peut faire avec les snapshots ainsi que la robustesse de btrfs et sa capacité (pour peu qu'on utilise du RAID) à se remettre d'une corruption de bloc.

N'hésitez pas à consulter les liens sources fournis dans la dépêche, à commencer par la vidéo de présentation évoquée plus haut. 48 minutes qui valent le détour, croyez-moi !

Aller plus loin

  • # Support de stockage

    Posté par  . Évalué à 2.

    Quand on a du SSD à la maison vaut-il mieux prendre ext4, brtfs, logfs ?

    de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité

    • [^] # Re: Support de stockage

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

      Ext4. Btrfs n'est pas prêt, et LogFS est inapproprié : il est conçu pour les flash à accès direct, par pour les périphériques avec émulation d'accès par blocs.

    • [^] # Re: Support de stockage

      Posté par  . Évalué à 3.

      Faut attendre que les fabricants virent la couche d'abstraction pour que le noyau fasse correctement son travail.

    • [^] # Re: Support de stockage

      Posté par  . Évalué à 3.

      Ext2. Si si, sérieux.
      Bon, boutade d'accord.
      Mais quand même Ext2 n'est pas à rejeter - ça dépend de ce que tu fais bien sûr. Il n'a pas de journal, mais est-ce tellement pénalisant en utilisation bureautique? En plus avec un SSD les fsck vont à toute vitesse.

      Je me demande en fait si avec un SSD, un utilisateur de bureau sentirait une grosse différence de vitesse entre "l'ancêtre" Ext2 et Ext4 ou Btrfs.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Support de stockage

        Posté par  . Évalué à 2.

        L'ext4 supporte la fonction TRIM (très importante pour les SSD, il paraît) avec l'option discard

        Ca ne semble pas être le cas pour ext3 ni ext2, ni aucun autre fs linux d'ailleurs (mis à part btrfs, quand il sera prêt).

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Support de stockage

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

          la fonction TRIM (très importante pour les SSD, il paraît)

          Il parait, mais j'ai un disque ssd acheté juste avant le "TRIM" et il n'a pas cette fonctionnalité, après quelques années il va toujours à la même vitesse soit 100Mo/sec en lecture. Donc c'est peut-être bien mais pour une utilisation style bureautique comme moi j'ai l'impression que ça ne sert à presque rien. Pour moi ça sent la bulle marketing.

          • [^] # Re: Support de stockage

            Posté par  . Évalué à 2.

            Hello,

            la fonction TRIM est pour garder de bonne perf en écriture.
            En effet, lors d'une suppression, les emplacements en mémoires sont marqués comme libre, mais pas effacé.
            Ce qui fait qu'en cas d'écriture au mêmes endroits, il s'ensuit une mise à zéro puis une écriture, d'où la perte de performance. Le trim met à zéro tout les emplacements marqués comme libre:

            [root@ustation ~]# fstrim -v /boot
            /boot: 419212288 bytes were trimmed
            [root@ustation ~]# fstrim -v /boot
            /boot: 0 bytes were trimmed

            Pour le moment cette opération n'est pas "queueable" ce qui fait qu'elle ne peut pas être effectuée après chaque suppression sans que le système attende la fin du trim et donc mette tous les io en attente.

            @+

        • [^] # Re: Support de stockage

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

          y a pas que discard pour activer le trim, il y aussi "l'autre trim" : le trim différé http://libre-ouvert.toile-libre.org/index.php?article72/ssd-crucial-m4-64-go-linux-trim-ext4-noatime#TRIM

      • [^] # Re: Support de stockage

        Posté par  . Évalué à 5.

        Mais quand même Ext2 n'est pas à rejeter - ça dépend de ce que tu fais bien sûr. Il n'a pas de journal, mais est-ce tellement pénalisant en utilisation bureautique? En plus avec un SSD les fsck vont à toute vitesse.

        Heuu l'intérêt d'un journal n'est pas seulement d'accélérer fsck, c'est surtout de réduire drastiquement les conséquences d'un crash système.

        Quant au coup de l'utilisation bureautique, outre que ça ne correspond pas forcément à l'utilisation que l'on fait d'un PC à la maison, les logiciels aujourd'hui ont tendance à avoir des fonctions de persistance assez poussées (penser à tous les déboires de Firefox avec ses bases SQLite), et donc à faire des écritures régulières. Ce serait dommage, par exemple, de perdre des mails si la machine crashe juste au moment où le lecteur de mails était en train de réécrire un fichier mbox.

        • [^] # Re: Support de stockage

          Posté par  . Évalué à 2.

          J'ai justement parlé d'utilisation bureautique, parce que c'est une des plus stable au niveau système.
          Dans ce genre de situation, et avec des disques durs, il m'arrive encore d'installer en Ext2 (pour la vitesse). Mais avec un SSD je doute qu'un utilisateur moyen perçoive la différence de vitesse entre Ext2 et Ext4 ou Btrfs. Parce qu'il y a beaucoup moins d'écritures que de lectures.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Le mode « 3 copies »

    Posté par  . Évalué à 9. Dernière modification le 20 février 2012 à 16:53.

    Le mode « 3 copies » : imaginez un RAID1 sur 3 blocs au lieu de 2 ;

    C'est quoi la différence avec 3 disques en RAID1 normal ? Je ne trouve pas à :en:Non-standard_RAID_levels.

    • [^] # Re: Le mode « 3 copies »

      Posté par  . Évalué à 2.

      Ben tu peux mettre plus de disques ;-)

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Le mode « 3 copies »

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

        Bah dans le RAID 1 tu peux en mettre quarante si tu veux.
        Le RAID 1 c'est copie conforme entre tout les disques, mais ils ne sont pas forcément deux, ils peuvent être plus, j'ai une partition en RAID 1 Linux dupliquée sur trois disques sur une de mes machines, et sans btrfs...

        Alors, quel est donc ce mode « 3 copies » ? Quelle différence avec du RAID 1 classique sur 3 disques ?
        Peut-être simplement que btrfs ne faisait pas ça avant ?

        Yth.

        • [^] # Re: Le mode « 3 copies »

          Posté par  . Évalué à 6.

          Le raid au sens btrfs n'est pas un raid au niveau des disques mais au niveau des extents. C'est une erreur très courante de comparer le fonctionnement du raid disque avec la "logique raid" utilisé par btrfs.

          Donc en gros ton fichier est stocké 3 fois dans 3 extents. De préférence btrfs répartira ces extents sur plusieurs disques, cela veut dire que tu peux avoir du raid 1 mode 3 activé avec deux disques seulement, les 3 extents contenant le même fichier seront répartis entre les n disques.

          • [^] # Re: Le mode « 3 copies »

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

            Ok, btrfs permet de répartir sur autre chose que des disques physiques, il intègre des notions de lvm et compagnie directement dedans.
            Mais le RAID 1 à 3 copies de btrfs correspond tout de même au RAID 1 classique sur trois disques : ton fichier est à trois endroits différents (que ce soient des extents, des disques, ce que tu veux), non ?

            En gros btrfs permet de faire du RAID 1 logiciel au dessus d'un fonctionnement type LVM, alors que seul l'inverse était possible avec les outils précédents : tu fait ton RAID 1 logiciel sur des partitions physiques, que tu amalgames sur un LVM.

            Mais la question ne porte pas là dessus, la question soulevée par JGO c'est de savoir ce que signifie exactement ce « RAID 1 3 copies » de btrfs, puisque la définition (théorique) du RAID 1 c'est que tu peux avoir n copies ?

            Yth.

            • [^] # Re: Le mode « 3 copies »

              Posté par  . Évalué à 0.

              C'est du raid 1 tout à fait standart paramétré pour faire 2 niveaux de redondance, du raid 1 ni plus ni moins. le côté 3 copie c'est du pipotage.

      • [^] # Re: Le mode « 3 copies »

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

        Tu peux déjà mettre autant de disques que tu veux sur un RAID1 normal...

  • # Pourquoi Oracle favorise-t-il btrfs ?

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

    Question d'un béotien : ZFS était un technologie de Sun, me semble-t-il. Oracle a donc dû en récupérer les fruits lors de son acquisition. Si les problèmes de ZFS ne sont que des problèmes de licence, Oracle ne peut-il pas tout simplement republier ZFS sous une autre licence ? Quel intérêt a-t-il à repartir de zéro (j'exagère un peu) avec un autre système comme btrfs ?

    • [^] # Re: Pourquoi Oracle favorise-t-il btrfs ?

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

      btrfs a été lancé avant le rachat de Sun. La question devient : quel intérêt ont-ils de continuer à développer btrfs ?

      • [^] # Re: Pourquoi Oracle favorise-t-il btrfs ?

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

        Avoir deux façades presque identiques (ou se ressemblant fortement) mais avec des technologies différentes (d'un coté, des briques, de l'autre du béton banché) ?

        (à garder pour 'dredi : p'is bon, y'en a un qu'est prêt, l'autre qu'est pas mûr... :o)

        Proverbe Alien : Sauvez la terre ? Mangez des humains !

        • [^] # Re: Pourquoi Oracle favorise-t-il btrfs ?

          Posté par  . Évalué à 3.

          p'is bon, y'en a un qu'est prêt, l'autre qu'est pas mûr...

          Oui enfin sauf qu'ils ne sont pas intégrer dans le même OS!
          Même s'ils changeaient la license de ZFS aujourd'hui, l'intégrer dans Linux ne serait pas si simple..

      • [^] # Re: Pourquoi Oracle favorise-t-il btrfs ?

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

        quel intérêt ont-ils de continuer à développer btrfs ?

        Peut-être une piste : Quand a été développé zds ? Où sont ceux qui ont créé et maintenu zfs ?

        Il n'est pas du tout évident de rentrer dans un projet qu'on n'a pas développé et même quand on revient sur ses propres logiciels quelques temps après, on n'est pas tout de suite opérationnel.
        Le File System doit fonctionner avec zéro bug. Nous avons déjà des FS qui fonctionnent bien, il n'y a pas urgence mais la nécessité de faire mieux.

        Je pense qu'il est plus simple de continuer un projet actif (btrfs) que de faire revivre un projet somnolent. D'autre part, est-ce que les options de base de zfs permettraient d'intégrer proprement de nouvelles fonctionnalités ? De bonnes bases, bien pensées, sont le gage d'une longue vie. Les verrues et les emplâtres en appellent d'autres. Quel est le cas de zfs ?

        J'ai beaucoup utilisé reiserfs et reiser4 était très séduisant. Il aurait pu être une alternative à btrfs. Mais je crains que ces fs ne soient tombés en désuétude quand Hans Reiser retrouvera la liberté. Quel gâchis !

        • [^] # Re: Pourquoi Oracle favorise-t-il btrfs ?

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 20 février 2012 à 18:15.

          Mais je crains que ces fs ne soient tombés en désuétude quand Hans Reiser retrouvera la liberté. Quel gâchis !

          Intéressant. Je ne connaissais pas les affaires sordides de M. Reiser...

          Nous avons déjà des FS qui fonctionnent bien, il n'y a pas urgence mais la nécessité de faire mieux.

          Ca me fait penser à une dépêche au sujet de l'annonce du noyau Linux 3.2 évoquant des améliorations d'Ext4 qui pourraient mener la vie dure à btrfs (du mois sur certains aspects), alors qu'il était plutôt envisagé comme un système de transition entre le vénérable Ext3 et son futur remplaçant "Next-Gen"...

          • [^] # Re: Pourquoi Oracle favorise-t-il btrfs ?

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

            Et j'imagine que le fait que le maintaineur d'ext4 qui bosse chez Google, embauché après le procès d'Oracle envers Google, n'est surement pour rien dans l'état de fait de "on pourrit le projet d'oracle en retirant l'avantage compétitif de btrfs". En fait, d'une maniére général que le karma d'Oracle ( libreoffice, jenkins, mariadb, etc, etc ) n'a sans doute eu aucune influence, bien sur.

    • [^] # Re: Pourquoi Oracle favorise-t-il btrfs ?

      Posté par  . Évalué à 6.

      Si je me souviens bien, une développeur de ZFS a déclaré que Btrfs avait une meilleure architecture que ZFS, ce dernier étant précurseur dans le domaine n'a pas pu bénéficier des recherches datant d'après sa création.

      « 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

  • # Toujours la même question

    Posté par  . Évalué à 5.

    Les modes RAID5 et RAID6

    J’avais déjà posé la question ici (je ne retrouve plus mon commentaire) : est-ce que c’est vraiment au système de fichier de gérer le RAID, le chiffrement, et tout ça ?

    • [^] # Re: Toujours la même question

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

      J'ai comme l'ipression que c'est ce qui sera[it] le plus efficace, oui...
      De savoir que faire entre LVM, Raid, système de fichier journalisé, UnionFS, etc. J'attends depuis longtemp un système de fichiers qui fait tout cela en même temps, de manière cohérente et optimisé...

      • [^] # Re: Toujours la même question

        Posté par  . Évalué à 3.

        Justement, je pense l’inverse.

        C’est un peu la différence entre UNIX et tout le reste : faire une (et une seule) chose et la faire correctement !

        • [^] # Re: Toujours la même question

          Posté par  . Évalué à 7.

          C'est la position que soutenait Linus Torvalds en refusant d'intégrer des FS qui ré-implémentaient tout et le reste, jusqu'à ce que ...

          Avec ZFS cette vision a commencé à être remise en cause. Justement il fait tout, le reste et le café en option et il se permet d'offrir des fonctionnalités et des performances globalement supérieures à ses concurrents.

          On se rend compte qu'en intégrant les choses on peut faire des optimisations. Là où LVM travaille sur des secteurs, ZFS/btrfs peuvent profiter de leur connaissance de la structure des fichiers pour les snapshots par exemple. Quand on modifie une structure plus petite qu'un secteur, pas besoin de copier tout le secteur, une copie de la struture impliquée suffit. Bref, au final les arguments des spécialistes de FS pour cette intégration ont été les plus forts.

        • [^] # Re: Toujours la même question

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

          En pratique, tu t'apercois que tout le monde veut que ça fasse une chose, à savoir ce qu'il veut, mais ce qui reviens à faire plein de choses, et tout le monde veut que ça fasse ça correctement. Donc on pourrais dire que le succés d'unix a été de faire ce que les gens voulaient correctement. Le reste n'est que détail d'implémentation, et ça dépend grandement de ce que tu appelles "chose".

          Est ce que gerer des pipes nommés, des sockets, des liens symboliques, des repertoires , c'est faire une seule chose ?
          Est ce que le firewall doit aller dans le kernel ? Est ce que "gerer un fs" n'est pas faire une chose ? Et gérer le matériel ?

          Il y a plusieurs niveaux de précisions, et tot ou tard, tu va trouver un truc qui fait une chose. Ce qui veut as dire qu'au dessus, ça soit le cas.

          Et comme la fameuse citation de Gandi, je trouve que cet aphorisme est usé jusqu'à la corde, sorti de son contexte historique et peu à peu vidé de sens, mais c'est que mon avis.

      • [^] # Re: Toujours la même question

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

        Et la philosophie UNIX, on en fait quoi ? Un outil pour une tâche, et des outils qui communiquent entre eux ?

        • [^] # Re: Toujours lamêmequestion

          Posté par  . Évalué à 10.

          Oulà, doucement avec la philosophie Unix. La colle qui unit tous ces outils, c’est le shell, le truc un peu bâtard, mi langage de programmation, mi interface utilisateur. Un truc qui sert à gérer la hiérarchie de fichiers (via cp, mv, ls & co), à faire du traitement de texte (via tr, sed, less, cat, etc.), ou encore à gérer les processus (nice, &, jobs, fg, bg, C-Z), ou leur communication avec des performances désastreuses (les entrées/sorties avec le tube). Bref un truc sous-optimal (mais un couteau suisse super souple) !

          De plus, où situer la barre pour identifier si un ensemble de fonctionnalités doit être scindé ou fusionné ? Après tout le moindre éditeur fera très certainement du remplacement, n’est-ce pas pourtant dévolu à sed ? Pourquoi d’un autre côté avoir tout de même un sed, à quoi sert tr alors ? Notons que sed, puisque l’exemple me plait bien, a une effusion de fonctionnalités, avec un langage propre à lui (et ne parlons pas de awk).

          Pour finir remarquons que la philosophie unix est essentiellement horizontale : on empile pas les couche, mais chaque élément communique avec l’autre plutôt que de s’appuyer dessus.

          La question se pose alors pour un système de fichier, fondamentalement son but est de gérer nos disques. Alors pourquoi empiler les couches ? C’est-à-dire d’abord transformer les volumes physiques en volumes logiques, ensuite avec ces volumes logiques faire des partitions, ensuite à partir de ses partitions gérer un chiffrage, puis encore par dessus le système de fichier.

          Deux hypothèses :
          — Soit séparer chaque fonction a un coût négligeable (et a donc tout intérêt à la séparation), dans ce cas il y a tout intérêt à le faire et ce sera fait dans btrfs, alors le problème n’est qu’une histoire de nom (c’est juste qu’on appelle l’ensemble btrfs). Sachant que les différents outils séparés existent toujours pour celui qui veut de la souplesse (lvm&co), c’est-à-dire des éléments interchangeables.
          — Soit il y a des gains notables et dans ce cas il est pertinent de regrouper les choses (car il ne faut pas oublier que la philosophie Unix s’appliquent aux outils de « haut niveau » et qu’elle conduit à des performances déplorables).

          Pour appuyer mon propos, un petit extrait de man btrfs :

          SYNOPSIS
       btrfs subvolume snapshot <source> [<dest>/]<name>

       btrfs subvolume delete <subvolume>

       btrfs subvolume create [<dest>/]<name>

       btrfs subvolume list <path>

       btrfs subvolume set-default <id> <path>

       btrfs filesystem defrag <file>|<dir> [<file>|<dir>...]

       btrfs filesystem sync <path>

       btrfs filesystem resize [+/-]<size>[gkm]|max <filesystem>

       btrfs device scan [<device> [<device>..]]

       btrfs device show <dev>|<label> [<dev>|<label>...]

       btrfs device balance <path>

       btrfs device add <dev> [<dev>..] <path>

       btrfs device delete <dev> [<dev>..] <path> ]

          Nul doute que le binaire en question commence par un bon gros équivalent à un switch des cavernes sur la commande en premier argument. Il est alors plus question d’esthétique que de philosophie pour faire un binaire machin-subvolume, un autre btrfs-filesystem, et enfin truc-device. De pauvres liens symboliques dans le bin et tu n’y aurais vu que du feu ! :P

          Pour finir, de ce que j’ai compris de btrfs, tout est représenté sous forme d’arbre, données, méta-données, et j’en passe, tout passe par la même structure, le fameux copy-on-write B-tree. Il y a fort à parier que l’ajout de fonctionnalités était surtout du pissage de code plus que de la conception (totalement dédié à un B-tree performant et fiable). Et vu qu’au final btrfs a évolué plutôt vite il me semble, et qu’on se retrouve avec le fsck qui tarde, je ne pense pas que le bousin soit un grosse usine à gaz.

          • [^] # Re: Toujours lamêmequestion

            Posté par  . Évalué à 2.

            La colle qui unit tous ces outils, c’est le shell, le truc un peu bâtard, mi langage de programmation, mi interface utilisateur.

            En même temps, si t’enlève les if, while, case, t’enlève une partie de cette colle.

            à gérer la hiérarchie de fichiers (via cp, mv, ls & co)

            Rien à voir avec le shell, c’est cp, ls, mv qui le font.

            à faire du traitement de texte (via tr, sed, less, cat, etc.)

            Rien à voir avec le shell, c’est tr, sed, less, cat qui le font.

            ou encore à gérer les processus (nice, &, jobs, fg, bg, C-Z)

            Rien à voir avec le shell, c’est nice qui le fait. Les 4 autres permettent seulement les processus du shell (pas les autres).

            De plus, où situer la barre pour identifier si un ensemble de fonctionnalités doit être scindé ou fusionné ? Après tout le moindre éditeur fera très certainement du remplacement, n’est-ce pas pourtant dévolu à sed ?

            C’est pas parce que « tout le monde le fait » (utiliser son propre chercher-remplacer) qu’il faut pas le remettre en question.

            Pourquoi d’un autre côté avoir tout de même un sed, à quoi sert tr alors ?

            Personne n’a jamais dit qu’il ne fallait pas avoir 50 outils différents, c’est tout le contraire. D’ailleurs tr est là plutôt pour des raisons historiques non (enfin, je m’en sert de temps en temps) ?

            Il y a fort à parier que l’ajout de fonctionnalités était surtout du pissage de code plus que de la conception (totalement dédié à un B-tree performant et fiable).

            Du code, qu’il soit « pisser » ou « conçu » apporte sont lot de bug…

            • [^] # Re: Toujours lamêmequestion

              Posté par  . Évalué à 3.

              Rien à voir avec le shell, c’est tr, sed, less, cat qui le font.

              Sauf que non, ça n'a pas rien à voir. Sans un moyen très aisé de les combiner entre eux, beaucoup de ces outils pris individuellement n'auraient pas grand intérêt. Et ce moyen très aisé de les combiner entre eux, c'est bien le shell qui le fournit.

              • [^] # Re: Toujours lamêmequestion

                Posté par  . Évalué à 0.

                Donc, ce n’est pas le Shell qui fait ça, ce sont ces outils. Le Shell n’apporte qu’une interface pour gérer ces outils et les lier entre-eux.

                C’est exactement ce que j’ai dit.

                • [^] # Re: Toujours lamêmequestion

                  Posté par  . Évalué à 5.

                  Là où je voulais en venir, désolé si je n’ai pas été assez explicite, est que la philosophie Unix induit la nécessité d’un shell. Tous les outils cités se conçoivent comme appelés depuis un shell (peut-être existe-t-il d’autres façons de s’en servir, mais je n’en n’ai jamais rencontrées, dans tous les cas on peut les supposer marginales). Or le shell est à l’opposé du paradigme « un outil, une tâche », autant dans les usages auxquels il répond que dans son fonctionnement interne. C’est pour moi un archétype de l’usine à gaz :

                  man bash|wc -l
                  4095

                  Ça ne l’empêche pas d’être extrêmement puissant et fiable, mais c’est bougrement paradoxal.

                  • [^] # Re: Toujours lamêmequestion

                    Posté par  . Évalué à -3.

                    C’est pour moi un archétype de l’usine à gaz :

                    Tu peux coder un shell minime (non-POSIX du coup) avec juste des execv…

                    man bash|wc -l
                    4095

                    Allons-y dans les comparaisons foireuse :

                    (arcaik) |> ~ <| man zsh | wc -l
247

                    • [^] # Re: Toujours lamêmequestion

                      Posté par  . Évalué à 7. 

                      man zshall | wc -l
15974

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

          • [^] # Re: Toujours lamêmequestion

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

            Je dois avouer que j'ai lancé cette question un peu "comme ça", pour la discussion. Même Dieter Plaetinck, le concepteur de uzbl, a admis les faiblesses de cette approche :

            The main lesson I learned from doing uzbl is: the very ideology-based approach of "one program for each thing" is nice in theory, but can become a hassle in practice. The means of IPC are limited: passing command line arguments, setting environment variables, or creating your own little protocol that needs to be parsed. Advanced constructs like loops and branches complicate things more, and when passing stuff through various processes like we did, it can be tricky to figure out how to quote your strings so that they are expanded at the right stage. It's also hard to jump between various pieces of code; the separation between processes start to feel like real barriers.

            Dans l'absolu, je suis d'accord, on devrait avoir une seule interface entre mes fichiers et le disque même. Mais maintenant que je sais que des choses comme LVM ou le RAID existent (même si ce dernier est pas forcément tip-top), j'aimerais pouvoir les utiliser avec des FS différents, pour bidouiller.

            • [^] # Re: Toujours lamêmequestion

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

              Dans l'absolu, je suis d'accord, on devrait avoir une seule interface entre mes fichiers et le disque même. Mais maintenant que je sais que des choses comme LVM ou le RAID existent (même si ce dernier est pas forcément tip-top), j'aimerais pouvoir les utiliser avec des FS différents, pour bidouiller.

              Un peu comme GEOM ?

        • [^] # Re: Toujours la même question

          Posté par  . Évalué à 1.

          Et la philosophie UNIX, on en fait quoi ? Un outil pour une tâche, et des outils qui communiquent entre eux ?

          Comme GNU Hurd ?

      • [^] # Re: Toujours la même question

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

        Si on veut un système qui fait tout, de manière cohérente, maintenable dans le temps, sur, etc. cela signifie en pratique que le projet est structuré en module le plus orthogonal possible avec une API claire, documenté et qui ne change pas tous les quatre matins.

        En gros, cela reviendrait à terme à faire remonter dans LVM, le système RAID... petit à petit les API et les algorithmes pour les faire partager entre tous les systèmes de fichiers.

        Il y a déjà plusieurs système de RAID1 dans le noyau... Il n'est pas impossible qu'à terme, tous ces systèmes convergent et s'unifient.

        • [^] # Re: Toujours la même question

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

          Des APIs claires et séparées, c'est pas comme ça qu'on aboutit à des systèmes architecturellement propres comme les classes de base de java ( avec une classe qui fait une chose et une seule ). Y a des gens qui trouvent que ça fait bloat, personnellement je pense que non, mais il est très claire que la modularité n'est pas gratuite, et donc son usage à outrance a un cout.

    • [^] # Re: Toujours la même question

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

      https://blogs.oracle.com/bonwick/entry/zfs_end_to_end_data
      http://www.reed.com/dpr/locus/Papers/EndtoEnd.html

      The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Toujours la même question

      Posté par  . Évalué à 3.

      J’avais déjà posé la question ici (je ne retrouve plus mon commentaire) : est-ce que c’est vraiment au système de fichier de gérer le RAID, le chiffrement, et tout ça ?

      Ça a certains avantages. Par exemple, ça permettra (lorsque ce sera implémenté) d'avoir différents niveaux de RAID pour différents dossiers, de ne chiffrer que certaines parties du système de fichier, etc.

    • [^] # Re: Toujours la même question

      Posté par  . Évalué à 2.

      La logique de raid ou de chiffrement peut exister à plusieurs niveaux.

      Si tu souhaites faire de la tolérance de panne de tes disques, le raid au sens btrfs n'est pas le plus pertinent, en effet un disque peut contenir plusieurs partition, pour des usages différents.

      Si tu souhaites faire de la tolérance à la corruption de données, là tu situes ton problème plus au niveau du système de fichier donc la logique raid au niveau du système de fichier est plus pertinente.

      Les combos luks+raid+lvm selon les cas d'utilisation seront toujours plus pertinents. Mais dans beaucoup de cas, les besoins sont beaucoup plus simple.

      Donc pour conclure il ne faut pas penser que btrfs cherche à remplacer ce qui existe déjà, mais plutôt à répondre à certains besoins de façon plus pertinente.

  • # Et les attributs étendus ?

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

    Quid des xattrs ?
    Étant utilisateur de Haiku, je suis toujours frustré de voir l'état lamentable du support des xattrs dans GNU/Linux, y compris sur les systèmes de fichiers... 1 bloc / inœud dans ext ça pue vraiment grave quoi ! Ext4 n'a rien apporté à ce sujet malheureusement. J'ai l'impression qu'il va falloir leur en parler avant qu'il soit trop tard.
    Pourtant c'est très important malheureusement, il y a de nombreux problèmes à résoudre à ce sujet.
    cf. mon papier à DC-2011 : http://dcevents.dublincore.org/index.php/IntConf/dc-2011/paper/view/53

  • # En parlant du raid

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

    un article intéressant sur le sujet :
    http://richardhartmann.de/blog/posts/2012/02/RAID-sucks/

Suivre le flux des commentaires

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