Journal [Btrfs et openSUSE] Épisode 0 : l'ex-fs du futur

Posté par . Licence CC by-sa
Tags :
59
14
août
2017

Sommaire

Je suis…

Indice chez vous

… un système de fichiers, encore considéré par beaucoup comme expérimental dix ans après le début de mon développement, Red Hat m'a déprécié tout récemment, une seule distribution – openSUSE – a osé me placer comme fs par défaut mais ses utilisateurs me rejettent et me préfèrent ext4, je suis, je suis ?

- …
- Btrfs !

Présenté comme ça, ça ne donne pas très envie. Mais, pas de bol, c'est pourtant ce truc qui m'intéresse en ce moment et c'est ce dont je vais vous parler maintenant.

Voici donc l'épisode 0 de « Btrfs et openSUSE », une série de journaux sur le système de fichiers Btrfs, basée sur ma propre expérience d'utilisateur d'openSUSE. Ce qui, je vous l'accorde, n'est pas très rassurant :-) Dans cette série, il y aura :

  • des généralités sur Btrfs
  • des noms qui pètent : sous-volumes, snapshots, rollbacks
  • du snapper
  • du grub
  • de la mise à jour incrémentale
  • des quotas
  • de la maintenance
  • des trucs spécifiques à openSUSE
  • des tentatives désespérées pour rester applicable à d'autres distributions
  • des erreurs (pas taper)
  • des bugs
  • des cris
  • des larmes
  • et bien plus ! ou bien moins

Btrfs is hard

Btrfs : l'ex-fs du futur

Juste pour vous résumer rapidement ce qu'est Btrfs – du moins ce que j'en comprends.

tl;dr - Btrfs est un système de fichiers basé sur un arbre B et la technique du CoW ; il offre des fonctionnalités nouvelles (comparé à notre bon vieux ext4).

Arbre B

Je vous invite à lire son article sur Wikipédia. En gros, c'est simplement un arbre binaire de recherche avec des nœuds parents qui peuvent avoir plus de deux nœuds enfants.

Voici un joli schéma.

schéma
(r = racine, k = clé, c = enfant)

Je vous avais dit qu'il était beau !

Bon, vous allez être déçu – ou pas : je ne vous en dirai pas plus. Je ne vous parlerai pas non plus de son implémentation dans Btrfs. Parce que je n'y connais rien, certes… J'ai quand même pensé à vous et j'ai mis des liens plus bas qui pourront assouvir votre soif de connaissance ;-)

Avantage : certaines opérations - dont la vérification du système de fichiers - sont rapides.

Inconvénient : il faut équilibrer l'arbre régulièrement (maintenance). FAQ btrfs sur l'équilibrage

CoW : Copy-on-Write

        ______________________________
       /  ____________                \
       | < cowception >               |
       |  ------------                |
       |         \   ^__^             |
       |          \  (oo)\_______     |
       |             (__)\       )\/\ |
       |                 ||----w |    |
       |                 ||     ||    |
       \                              /
        ------------------------------
                            \   ^__^
                             \  (oo)\_______
                                (__)\       )\/\
                                    ||----w |
                                    ||     ||

Qu'est-ce don' ?

Quand on crée de nouvelles données, on les écrit sur un espace libre et on marque les métadonnées comme étant du CoW.

Quand veut modifier les données :

  1. On voit dans les métadonnées que c'est du CoW
  2. Au lieu d'écraser directement les données qui diffèrent, on les écrit sur de l'espace libre
  3. On met à jour les métadonnées pour pointer vers les nouvelles données

Lazy copy

Le Copy-on-Write, c'est pratique pour faire de la copie paresseuse.

Cela consiste à ne pas vraiment copier une donnée quand on nous le demande, mais uniquement de créer des métadonnées qui pointeront vers la donnée originale. On n'écrit une donnée que quand l'original ou la pseudo-copie commence à bouger.

Exemple de code C++

Exemple honteusement pompé sur Wikipédia :

std::string x("Hello");
std::string y = x;  // x et y utilisent le même tampon
y += ", World!";    // maintenant y utilise un tampon différent
                    // x continue à utiliser le même buffer
Exemple avec Btrfs

Exemple honteusement inspiré d'un topic sur StackExchange.

Créons un fichier x et une copie paresseuse y via cp --reflink :

~# yes "hello" | head -n 1000 > x
~# cp --reflink x y
~# ls -i x y
273 x  275 y # ce sont les numéros d'inode
~# btrfs inspect-internal dump-tree /dev/vdc1
[]
    # Notre x
    item 4 key (273 INODE_ITEM 0) itemoff 15889 itemsize 160
        inode generation 28 transid 28 size 6000 nbytes 8192
        block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
        sequence 0 flags 0x8(none)
        atime 1502314234.215991766 (2017-08-09 23:30:34)
        ctime 1502314234.219991832 (2017-08-09 23:30:34)
        mtime 1502314234.219991832 (2017-08-09 23:30:34)
        otime 1502314234.215991766 (2017-08-09 23:30:34)
    item 5 key (273 INODE_REF 256) itemoff 15878 itemsize 11
        inode ref index 18 namelen 1 name: x
    item 6 key (273 EXTENT_DATA 0) itemoff 15825 itemsize 53
        generation 28 type 1 (regular)
        extent data disk byte 12582912 nr 8192 # les données
        extent data offset 0 nr 8192 ram 8192  # sont là
        extent compression 0 (none)
[]
    # Le y a une tête similaire
    item 16 key (275 INODE_ITEM 0) itemoff 14520 itemsize 160
        inode generation 29 transid 29 size 6000 nbytes 8192
        block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
        sequence 0 flags 0x4(none)
        atime 1502314493.220242255 (2017-08-09 23:34:53)
        ctime 1502314493.220242255 (2017-08-09 23:34:53)
        mtime 1502314493.220242255 (2017-08-09 23:34:53)
        otime 1502314493.220242255 (2017-08-09 23:34:53)
    item 17 key (275 INODE_REF 256) itemoff 14509 itemsize 11
        inode ref index 20 namelen 1 name: y
    item 18 key (275 EXTENT_DATA 0) itemoff 14456 itemsize 53
        generation 28 type 1 (regular)
        extent data disk byte 12582912 nr 8192 # oh ! c'est la même
        extent data offset 0 nr 8192 ram 8192  # chose que x !
        extent compression 0 (none)
[]
    # Un EXTENT_ITEM nous confirme qu'il y a bien partage
    item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16201 itemsize 82
        extent refs 2 gen 28 flags DATA # Cet élément compte deux références
        extent data backref root 256 objectid 273 offset 0 count 1 # 273 = x
        extent data backref root 256 objectid 275 offset 0 count 1 # 275 = y
[]
~#

On voit que x et y partagent les mêmes données.

Maintenant, modifions légèrement y (rajoutons-lui des données) :

~# yes "world" | head -n 1000 >> y
~# btrfs inspect-internal dump-tree /dev/vdc1
[]
    # On a toujours notre EXTENT_ITEM qui référence les "hello" de x et y
    item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16201 itemsize 82
        extent refs 2 gen 28 flags DATA
        extent data backref root 256 objectid 273 offset 0 count 1 # x
        extent data backref root 256 objectid 275 offset 0 count 1 # y
[]
    # On a maintenant y qui commence à faire sa vie tout seul avec ses "world"
    item 2 key (12591104 EXTENT_ITEM 8192) itemoff 16124 itemsize 53
        extent refs 1 gen 34 flags DATA
        extent data backref root 256 objectid 275 offset 4096 count 1
[]
~# filefrag x y
x: 1 extent found
y: 2 extents found
~#

x et y partagent toujours les mêmes données (les "hello"), mais y a un extent en plus pour les données qui lui sont propres (les "world").

Maintenant créons un tout nouveau contenu pour y :

~# yes "bonjour, je suis monsieur dupont" | head -n 1000 > y
~# btrfs inspect-internal dump-tree /dev/vdc1
[]
    # C'est officiel : x est maintenant tout seul
    item 0 key (12582912 EXTENT_ITEM 8192) itemoff 16230 itemsize 53
        extent refs 1 gen 28 flags DATA
        extent data backref root 256 objectid 273 offset 0 count 1 # 273 = x
[]
    # car y est parti
    item 2 key (12627968 EXTENT_ITEM 36864) itemoff 16153 itemsize 53
        extent refs 1 gen 43 flags DATA
        extent data backref root 256 objectid 275 offset 0 count 1 # 275 = y
[]
~#

Avantages & inconvénients

Plus ou moins.

Avantages :

  • Permettre de réaliser facilement des snapshots.
  • Éviter la duplication de données.
  • Opérations transactionnelles (la mise à jour des métadonnées est censée être atomique).

Inconvénients :

  • Ça fragmente.

Solutions :

  • Se reposer sur les stratégies de Btrfs pour limiter la fragmentation.
  • Défragmenter manuellement (maintenance).
  • Désactiver le CoW pour les fichiers/dossiers/sous-volumes qui reçoivent beaucoup d'écritures aléatoires.

Fonctionnalités

Liste au père Noël.

Maintenant qu'on a survolé les deux grands principes sur lesquels reposent Btrfs, arbre B et CoW, intéressons-nous aux fonctionnalités offertes.

On ne va pas se casser la tête et on va piocher directement sur le wiki du projet :

  • Stockage de fichier basé extent
  • Taille maximale par fichier : 264 octets == 16 EiB (en pratique, la limite tombe à 8 EiB à cause du VFS de Linux)
  • Stockage efficace de petits fichiers
  • Stockage indexé efficace des répertoires
  • Allocation dynamique d'inodes
  • Sous-volumes (~ systèmes de fichiers internes)
  • Instantanés en lecture seule ou en lecture-écriture
  • Sommes de contrôle sur les données et les métadonnées (crc32c)
  • Compression (zlib et LZO)
  • Prise en charge de plusieurs périphériques (RAID) :
    • File Striping (RAID 0)
    • File Mirroring (RAID 1)
    • File Striping+Mirroring (RAID 1+0)
    • Single et Dual Parity (RAID 5 et 6) : expérimental
  • Pour les SSD : TRIM/Discard et optimisations
  • Sauvegarde incrémentale
  • Défragmentation à chaud
  • Vérification du système de fichiers à froid
  • Conversion de systèmes de fichiers ext3 et ext4
  • « Périphériques graines » (seed devices). Des sortes de modèles de système de fichiers, en lecture-seule, que l'on peut copier sur d'autres systèmes de fichiers, si j'ai bien compris.
  • Prise en charge de quotas par groupes de sous-volumes (qgroup)
  • Envoi/réception de changements d'un sous-volume
  • Déduplication après écriture (la déduplication à la volée est expérimentale)

Les sujets en gras seront abordés dans les prochains épisodes de la série. Les sujets pas en gras seront peut-être abordés, mais rien n'est moins sûr.

J'espère que cet épisode introductif vous a plu et je vous laisse sur quelques liens.

That's all folks!

Liens

  • Le wiki du projet Btrfs.
  • BTRFS: The Linux B-tree Filesystem (ACM Digital Library), O. Rodeh, C. Mason, J. Bacik, ACM Transactions on Storage, Août 2013. Lien vers le texte complet disponible depuis la page personnelle de O. Rodeh.
  • B-trees, Shadowing, and Clones (ACM Digital Library), O. Rodeh, ACM Transactions on Storage, 2008. Lien vers le texte complet disponible depuis la page personnelle de O. Rodeh.
  • # Quelques précisions

    Posté par . Évalué à 6 (+5/-0).

    Merci d'essayer de clarifier Btrfs pour le commun des mortels, ce FS en a bien besoin.

    Quelque commentaires :

    • certains vont me dire suite à ma dernière dépêche que c'est vraiment mon dada de vouloir comparer à tout prix ;-) mais je pense qu'il faudrait expliquer le positionnement de Btrfs par rapport à ZFS et ext4 d'un point de vue utilisateur domestique/pro. De mon point vue utilisateur domestique :
      • Btrfs c'est comme ZFS, mais en gros (oui c'est trop simplifié) c'est moins abouti, il n'y a pas de problème de licence, et on a le dynamic resizing arrays (redéfinition du pool à chaud ?)
      • Par rapport à ext4, le FS a le CoW, est plus résistant à la corruption de données et permet une bonne déduplication.
    • je n'ai pas vraiment compris ton explication du CoW. Pour moi c'est simplement que l'on fait semblant de copier une donnée A en une donnée B au moment de la copie, et on ne fait réellement la copie que lorsque B est censé être modifié (et donc différent de A). Donc on ne copie que lorsque l'on modifie (Copy on Write !).
    • le point fondamental pour un FS, ce sont les limitations actuelles. Les fonctionnalités actuelles et futures, c'est bien. La réalité au jour d'aujourd'hui, c'est encore mieux. En particulier quand tout va bien, Btrfs se comporte bien (!), mais quand ton disque commence à lâcher, il faut faire TRÈS attention pour réparer.
    • [^] # Re: Quelques précisions

      Posté par . Évalué à -10 (+5/-15).

      il n'y a pas de problème de licence

      Au risque de paraître tatillon, ZFS n'a pas de problème de licence, c'est le noyau Linux qui en a un (et plus globalement la GPL/ le projet GNU ) :)
      Il semblerait d'ailleurs, vu les mouvements de Canonical avec l'inclusion d'OpenZFS par défaut sur les noyaux Ubuntu qu'il n'y ait aucun problème de licence.

      • [^] # Re: Quelques précisions

        Posté par . Évalué à 4 (+5/-2).

        Au risque de paraître tatillon, ZFS n'a pas de problème de licence, c'est le noyau Linux qui en a un (et plus globalement la GPL/ le projet GNU ) :)

        ZFS est sous licence CDDL et Linux sous licence GPL. Il n'y a aujourd'hui pas d'avis unanime à propos de la compatibilité entre les deux licences, d'où le problème.

        Il semblerait d'ailleurs, vu les mouvements de Canonical avec l'inclusion d'OpenZFS par défaut sur les noyaux Ubuntu qu'il n'y ait aucun problème de licence.

        Aucun problème de licence, circulez il n'y a rien à voir : nier le problème comme cela est sûrement très constructif pour faire avancer les choses.
        Je préfère donner un lien vers Wikipedia qui résume bien la situation : https://en.wikipedia.org/wiki/ZFS#Linux

        • [^] # Re: Quelques précisions

          Posté par (page perso) . Évalué à -2 (+4/-8). Dernière modification le 15/08/17 à 08:41.

          ZFS est sous licence CDDL

          Perso, je trouve dommage qu'ils ne passent pas à GPLv3.
          En effet, ça aurait été "rigolo" que les pro-GPL se retrouvent avec 2 gros morceaux intéressants en GPL (donc qu'ils aiment à fond, pour les deux logiciels) mais qu'ils soient incompatibles :).
          Avec la CDDL, on reste entre deux eaux (pas manifeste que ce soit non légal ou légal, et pas "tamponné FSF", zut)

          nier le problème comme cela est sûrement très constructif pour faire avancer les choses.

          Disons que les temps changent, la période de "je te fais peur" devient longue, qu'il y a plus d'1 an il y a une entité pas pauvre ("bankable") et pas non connue ("ça se sait") qui a osé défier la FSF sur leur analyse de la chose en estimant qu'il n'y avait pas de problème d'après leur lecture, et depuis la FSF n'a pas réagi. A un moment, on se dit que ceux qui disent qu'il y a un problème de légalité mais qui ne demandent pas à un juge de confirmer leur lecture sont comme SCO (ils FUDent). La FSF s'est mise dans une position qui ne peut que la rendre non crédible, à accuser sans demander qu'un tiers (un juge) valide cette accusation (et ce ne sera pas la première fois), et ça ne va pas aider pour la réputation des développeurs qui choisissent la GPL (on sait qu'on peut à tout moment être accusé gratuitement de violer leur licence et donc se prendre du troll sans que cette accusation ne soit "challengée" devant un tiers, ça devient de plus en plus un critère négatif quand on veut faire autre chose qu'utiliser le logiciel comme si on avait du proprio).

          • [^] # Re: Quelques précisions

            Posté par . Évalué à 3 (+2/-0).

            Si ZFS passent à GPLv3, Linus serait peut-être prêt à faire passer le noyau en GPLv3 ? ;-)

            And yes, maybe ZFS is worthwhile enough that I'm willing to go to the effort of trying to relicense the kernel.

            Bon c'était sans doute pour rire (mais on ne sait jamais avec ce Linus).

            nier le problème comme cela est sûrement très constructif pour faire avancer les choses.

            Disons que les temps changent, la période de "je te fais peur" devient longue

            Un an ce n'est pas très long, quand on voit le temps que cela a pris pour SCO vs Linux (qui est toujours devant les tribunaux d'ailleurs).
            C'est à partir du moment où on aura le cas devant un tribunal que cela va devenir intéressant.

      • [^] # Re: Quelques précisions

        Posté par . Évalué à 2 (+0/-0).

        Est-ce qu'il est inclu sous forme binaire ou compilé à chaque installation/maj. Ça change tout du point de vue respect de la licenve.

    • [^] # Re: Quelques précisions

      Posté par . Évalué à 1 (+1/-1).

      • je n'ai pas vraiment compris ton explication du CoW. Pour moi c'est simplement que l'on fait semblant de copier une donnée A en une donnée B au moment de la copie, et on ne fait réellement la copie que lorsque B est censé être modifié (et donc différent de A). Donc on ne copie que lorsque l'on modifie (Copy on Write !).

      Oui, tu as raison, c'est sans doute plus clair comme ça :-)

      J'ai essayé de donner une définition générale, inspirée entre autres de ce passage du wiki Btrfs, pour ne pas avoir exactement la même définition que pour la copie paresseuse. Mais au final, c'est du pareil au même.

      • [^] # Re: Quelques précisions

        Posté par . Évalué à -1 (+8/-5).

        [ sur la copie paresseuse (lazy copy) ]

        Oui, tu as raison, c'est sans doute plus clair comme ça :-)

        Non, il a tort et maintenant toi aussi. C'est non seulement moins clair comme ça, mais en plus c'est faux.

        Ta formulation dans le corps du journal est juste.

        Je reprends la formulation de SaintGermain< :

        je n'ai pas vraiment compris ton explication du CoW. Pour moi c'est simplement que l'on fait semblant de copier une donnée A en une donnée B au moment de la copie, et on ne fait réellement la copie que lorsque B est censé être modifié (et donc différent de A). Donc on ne copie que lorsque l'on modifie (Copy on Write !).

        Je traduis cette formulation dans une expression de meilleure qualité (ce qu'il a écrit est brouillon - je mets en italique le changement) :

        Pour moi, le CoW est simplement que l'on fait semblant de copier une donnée d'un emplacement A en un emplacement B au moment de la copie, et on ne fait réellement la copie que lorsque B est censé être modifié (et donc différent de A). Donc on ne copie que lorsque l'on modifie (Copy on Write !).

        Cette formulation est en fait une description partielle de la copie paresseuse (lazy copy) et non pas du CoW.

        En voici une formulation plus complète et maintenant valide :

        La copie paresseuse est le fait de créer une référence à l'original (cette référence constituant un substitut à une réelle copie) et ainsi de faire semblant de copier une donnée d'un emplacement A en un emplacement B. La copie est réellement faite lorsque la donnée est censée être modifiée, que ce soit à l'emplacement A ou B (la modification à l'un des deux emplacement impliquant une divergence de contenu, il est temps de réaliser la copie). Donc on ne copie réellement que lorsque l'on modifie.

        [ retour sur le CoW - définition non exhaustive ]

        Revenons à l'opération de Copy on Write (CoW) : l'enjeu primordial de limiter le risque de corruption de données (par une panne) lors d'une modification. Pour atteindre cet objectif, on ramène la modification proprement dite à une opération dite atomique (de taille la plus petite qui soit). Cette opération atomique est en fait la modification des méta-données qui donnent des informations sur les données proprement dites, dont leur emplacement sur le support de stockage (à la façon d'une table d'allocation). Pour n'avoir à modifier que les méta-données et ne pas toucher les données elles-mêmes, lors de l'opération de "modification" des données, ce qui est fait est une copie de celles-ci dans un autre emplacement. Ainsi, le CoW est une opération de copie lors d'une écriture (sous-entendu pour modification).

        [ traduction exhaustive du paragraphe Copy on Write (CoW) du SysadminGuide Btrfs ]

        Copie lors de l'écriture [Copy on Write (CoW)]

        • L'opération COW est utilisée lors de toutes les écritures sur le système de fichiers (à moins que le CoW soit désactivé, voir plus bas).
        • Cela rend beaucoup plus facile l'implémentation de la copie paresseuse, avec laquelle la copie est initialement seulement une référnce à l'original, mais dès que la copie (ou l'original) est changée, les deux versions divergent l'une de l'autre de la façon attendue.
        • Si vous ne faites qu'écrire un fichier qui n'existait pas avant, alors les données sont écrites dans un emplacement vide, et quelques uns des blocs de méta-données qui constituent le système de fichiers sont marqués de l'attibut "CoW". Dans un système de fichiers "normal", si vous voulez modifier une partie de ce fichier, alors la partie que vous ré-écrivez est placée directement par-dessus les données qu'elle remplace. Dans un système de fichiers CoW, les nouvelles données sont écrites à un emplacement libre sur le disque et seulement alors les méta-données du fichier sont changées pour référer aux nouvelles données. A ce moment, l'espace de stockage des anciennes données qui ont été remplacées peut être libéré, parce que plus rien ne pointe vers elles.
        • Si vous faites un snapshot (ou un cp --reflink=always) d'une portion de données, vous finissez avec deux fichiers qui référencent les mêmes données. Si vous modifiez un de ces fichiers, l'opération CoW décrite au-dessus se produit encore : les nouvelles données sont écrites quelque part ailleurs et les méta-données du fichier sont mises à jour pour pointer vers ces nouvelles données, mais les données originales sont gardées, parce qu'elles sont toujours référencées par l'autre fichier.
          • Cela mène à la fragmentation dans les fichiers lourdement mis à jour sur place, tels que les images de VM [Virtual Machine : machine virtuelle] et les stockages de base de données.
          • Notez que cela se produit même si les données ne sont pas partagées, parce que les données sont stockées en segments et seulement la partie nouvellement mise à jour d'un segment est sujette à l'opération CoW.
        • Si vous montez le système de fichiers avec nodatacow ou utilisez chattr +C sur le fichier, alors l'opération Cow est seulement effectuée pour les données qui ont plus d'une copie référencée.
        • Quelques personnes insistent sur le fait que Btrfs fait du "Redirect-on-write" plutôt que du "Copy-on-write" parce que Btrfs est basé sur un schéma pour les mises à jour des B-trees basées sur la redirection (par Ohad Rodeh) et parce que comprendre le code est plus facile avec cette façon de penser.
        • [^] # Re: Quelques précisions

          Posté par . Évalué à -7 (+3/-6).

          Correction - il manquait le verbe être (*), rajouté ici en italique :

          l'enjeu primordial est de limiter le risque de corruption de données (par une panne) lors d'une modification.

          (*) S'il manque le verbe, ça ne compile pas et si ça ne compile pas, Zin[o|d] s'en plaint.

        • [^] # Re: Quelques précisions

          Posté par . Évalué à -6 (+2/-4).

          J'ai écrit que l'enjeu primordial est de limiter le risque de corruption de données (par une panne) lors d'une modification.

          En fait, je ne sais pas si c'est vraiment l'enjeu primordial. Je ne suis pas dans la tête des concepteurs. AR7< a résumé ainsi les avantages dans le journal :

          • Permettre de réaliser facilement des snapshots.
          • Éviter la duplication de données.
          • Opérations transactionnelles (la mise à jour des métadonnées est censée être atomique).
          • [^] # Re: Quelques précisions

            Posté par . Évalué à -7 (+1/-4). Dernière modification le 15/08/17 à 14:56.

            En réfléchissant plus avant sur l'articulation entre Copy on Write (CoW) et copie paresseuse (cf. le commentaire résumé à titre pédagogique, plus bas) , j'identifie ceci :

            • l'enjeu direct du CoW est de limiter la corruption de donnée ;
            • les enjeux dérivés sont de permettre de réaliser facilement des snapshots et d'éviter la duplication de données (ces enjeux sont dérivés parce que le CoW facilite l'implémentation de la copie paresseuse et que c'est cette dernière qui amène directement ces avantages).

            Note : en quoi le CoW facilite-t-il l'implémentation de la copie paresseuse ? Voici : la copie paresseuse consiste dans un premier temps à différer la copie réelle de données (en commençant par créer une référence aux données originelles) et finit dans un deuxième temps, éventuellement, par aboutir à une copie réelle des données elle-mêmes lors d'une modification de la copie ou de l'original. C'est dans ce deuxième temps que se manifeste l'intérêt du Cow, qui consiste à copier réellement des données lors d'une simple modification. Il me semble que si le CoW est implémenté, le codage du deuxième temps de la copie paresseuse est facilité, car les meta-données liées au CoW peuvent permettre de tracer l'évolution des différentes références et donc de déclencher la copie réelle. Si quelqu'un en sait plus sur cet aspect, je suis preneur.

        • [^] # Re: Quelques précisions

          Posté par . Évalué à -6 (+1/-3).

          Pour résumer, à titre pédagogique, en centrant sur la question de SaintGermain< :

          • L'opération Copy on Write (CoW) se manifeste particulièrement lors de la modification d'un fichier : elle commence par la copie réelle du fichier (en tout ou partie) et se termine par la modification des méta-données.

          • L'opération de copie paresseuse consiste à différer la copie réelle en écrivant une nouvelle référence aux données prétendument copiées, puis en copiant réellement à l'occasion d'une modification de l'original ou de la copie, parce que l'une et l'autre vont diverger.

          • [^] # Re: Quelques précisions

            Posté par . Évalué à 2 (+1/-0).

            Je ne comprends pas la distinction que tu fais : il me semble que tu décris simplement les deux étapes du même fonctionnement, non ?

            La copie sur écriture / différée fonctionne comme ça :

            • Les données manipulées sont inaltérables (une référence à ces données pointera toujours sur les mêmes données dans le futur, elles ne seront jamais modifiées).
            • Faire une copie est extrêmement simple, puisqu'il suffit de faire une copie de la référence aux données.
            • Les modifications sont plus complexes puisqu'il ne faut pas modifier les anciennes données. À ce moment on est obligé de copier tout ou partie des anciennes données et de créer une nouvelle version des méta-données pour qu'elle pointe sur ces nouvelles données sans altérer les anciennes méta-données (récursivement, il s'agit d'un arbre).

            Bon, là ce serait plus facile à comprendre avec un dessin… en gros je veux une copie modifiée d'un arbre (un nœud remplacé), je dois faire une copie de ce nœud et de tous ses nœuds ancêtres, jusqu'à la racine ; ce nouvel arbre a une nouvelle racine, les nœuds sur la branche recréée peuvent référencer aussi d'anciens nœuds dans l'arbre. L'ancien arbre n'a pas été modifié (la racine pointe toujours vers le même arbre, exactement), la nouvelle racine référence un arbre constitué d'anciens et de nouveaux nœuds.

            Pour l'implémentation dans Btrfs je ne connais pas les détails par contre…

            • [^] # Re: Quelques précisions

              Posté par . Évalué à -6 (+1/-3).

              Merci pour cette présentation bien pédagogique avec notamment le lien entre la copie sur écriture / différée (alias Copy on Write) et l'arbre B (B-tree en anglais).

              Cette présentation, que je suppose parfaitement valide, n'est pas compatible avec la définition que j'ai donnée de l'opération Copy on Write (CoW), tirée du paragraphe Copy on Write (CoW) du SysadminGuide Btrfs, opération se manifestant particulièrement lors de la modification d'un fichier et commençant par la copie réelle du fichier.

              J'ai rédigé un commentaire complémentaire avant de lire ta réaction. J'y développe ma surprise à voir une incohérence entre la définition de CoW sur laquelle je m'appuyais (tirée du SysadminGuide Btrfs) et celle qui figure sur la page dédiée au CoW sur le Wikipédia anglophone.

              • [^] # Re: Quelques précisions

                Posté par . Évalué à -3 (+2/-1).

                [ toutes mes excuses pour le bruit ]

                En revenant une nouvelle fois à froid sur tout ça, je m'aperçois que j'ai du faire une confusion mentale entre copie et modification, en cours de route et à répétition…

                Je réponds maintenant à la question d'ylsul< :

                Je ne comprends pas la distinction que tu fais : il me semble que tu décris simplement les deux étapes du même fonctionnement, non ?

                Réponse : oui /o\

                Ainsi, lors d'une copie paresseuse d'un fichier, il y a :

                • création d'une référence aux données prétendument copiées ;
                • puis, à l'occasion d'une modification de l'original ou de la copie (l'une et l'autre vont diverger), il y a copie sur écriture / différée (alias Copy on Write) via le mécanisme suivant : copie réelle du fichier (en tout ou partie) puis modification des méta-données.

                Je pense que là j'ai bien articulé tout les concepts.

                Du coup, pour finir le boulot et nettoyer les faux problèmes que j'ai soulevés :

                a) dans mon commentaire parent, je me trompe lorsque j'écris ceci :

                Cette présentation, que je suppose parfaitement valide, n'est pas compatible avec la définition que j'ai donnée de l'opération Copy on Write (CoW), tirée du paragraphe Copy on Write (CoW) du SysadminGuide Btrfs, opération se manifestant particulièrement lors de la modification d'un fichier et commençant par la copie réelle du fichier.

                Non, la présentation d'ylsul< n'est pas incompatible avec le principe du Copy on Write selon la définition que j'ai proposée. Au passage, j'avais oublié d'ajouter la mention (en toute ou partie) dans ma réponse, à propos de la copie réelle du fichier.

                b) la définition proposée au paragraphe Copy on Write (CoW) du SysadminGuide Btrfs n'est pas erronée et n'est pas incompatible avec la définition de Wikipédia.

                Je formule de plates excuses auprès de tous les lecteurs pour avoir abondamment alimenté un questionnement biaisé.

                J'écris tout ça à froid, mais en fait c'est encore chaud… je veux dire par là que je n'ai pas peut-être pas tout décanté ni débuggé l'ensemble de ma prose. Je reviendrai si besoin sur un point ou un autre pour mieux mettre en évidence mes erreurs et laisser ainsi apparaître clairement valide tout ce qui l'est parmi tout ce que j'ai écrit.

                • [^] # Re: Quelques précisions

                  Posté par . Évalué à -4 (+1/-1).

                  En reprenant encore la définition du CoW dans le Wikipédia anglophone, telle que je l'ai analysée plus bas, je vois une correction à apporter à ma prose.

                  Selon l'analyse que j'ai faite de l'article Wikipédia (non pas l'article lui-même) au paragraphe [ quasi-conformité de ta définition du CoW avec le wikipédia anglophone ], le CoW est l'ensemble de la copie paresseuse, incluant les deux étapes suivantes : création d'une référence lors d'une requête de copie / copie réelle (partielle ou totale) [suivie d'une modification des méta-données], lors d'une requête de modification de l'original ou de la copie.

                  C'est ce que j'écrivais par ce paragraphe :

                  Pour rappel et en résumé, voici la définition [du CoW selon Wikipédia] : l'opération consiste à différer la copie réelle en écrivant une nouvelle référence aux données prétendument copiées, puis en copiant réellement à l'occasion d'une modification de l'original ou de la copie, parce que l'une et l'autre vont diverger.

                  En écrivant cela, je me trompais.

                  En fait, dans l'article Wikipédia, le CoW ne comprend pas le principe de création de référence lors de la requête de copie (ce principe précède l'étape du CoW).

                  Le CoW renvoie seulement à la copie réelle (partielle ou totale) lors d'une requête de modification [suivie d'une modification des méta-données, aspect qui est éludé sur l'article Wikipédia]. C'est d'ailleurs ce fait que je décris au paragraphe [ nuance conceptuelle sur le wikipédia anglophone à propos du CoW dans le stockage informatique ]

                  Ainsi, je me trouve confirmé dans l'idée que l'articulation des concepts est valide dans ma présentation de la copie paresseuse au commentaire parent.

        • [^] # Re: Quelques précisions

          Posté par . Évalué à 1 (+0/-0).

          J'avoue que je ne comprends toujours pas la différence entre CoW et la copie paresseuse.
          Sur Wikipedia, le CoW est décrit ainsi :

          If a resource is duplicated but not modified, it is not necessary to create a new resource; the resource can be shared between the copy and the original. Modifications must still create a copy, hence the technique: the copy operation is deferred to the first write.

          Ce qui me semble être en phase avec ce que j'ai écrit :

          on fait semblant de copier une donnée A en une donnée B au moment de la copie, et on ne fait réellement la copie que lorsque B est censé être modifié (et donc différent de A). Donc on ne copie que lorsque l'on modifie

          Si quelqu'un pouvait éclairer ma lanterne ?

          Merci

          • [^] # Re: Quelques précisions

            Posté par . Évalué à -5 (+3/-4). Dernière modification le 15/08/17 à 18:17.

            [ contexte d'expression de mon expertise toute relative ]

            J'ai vu passer l'expression Copy on Write (CoW) dans les commentaires sur Linuxfr.org au fil des années, alors que je ne la connaissais pas. J'ai toujours différé l'approfondissement de ce concept. A l'occasion des contributions ci-dessus, j'ai approfondi la question à partir du paragraphe Copy on Write (CoW) du SysadminGuide Btrfs que j'ai traduit.

            [ quasi-conformité de ta définition du CoW avec le wikipédia anglophone ]

            Je viens de lire attentivement toute la page en anglais Copy-on-write d'où tu as tiré la phrase que tu cites.

            Effectivement, la définition qui y est proposée est conforme à la définition que j'ai donnée de la copie paresseuse et donc conforme à ta définition du CoW, si tu veux, à deux remarques près (*) et cela aussi bien dans l'introduction que dans les trois paragraphes concernant l'usage du CoW dans la gestion de la mémoire virtuelle, dans les logiciels (le code des bibliothèques, des applications, des systèmes d'exploitation) et dans le stockage informatique.

            Pour rappel et en résumé, voici la définition : l'opération consiste à différer la copie réelle en écrivant une nouvelle référence aux données prétendument copiées, puis en copiant réellement à l'occasion d'une modification de l'original ou de la copie, parce que l'une et l'autre vont diverger.

            (*) voici les deux remarques :

            • j'ai remplacé ton expression « copier une donnée A en une donnée B » par l'expression « copier une donnée d'un emplacement A en un emplacement B », puisque c'est une même donnée copiée dans deux emplacements distincts ;
            • j'ai remplacé ton expression « on ne fait réellement la copie que lorsque B est censé être modifié (et donc différent de A) » par une expression indiquant que le déclencheur de la copie réelle est la tentative de modification de B ou de A, pas seulement de B : « la copie est réellement faite lorsque la donnée est censée être modifiée, que ce soit à l'emplacement A ou B (la modification à l'un des deux emplacements impliquant une divergence de contenu, il est temps de réaliser la copie) ».

            [ non conformité de la définition du wikipédia anglophone avec la définition tirée du SysadminGuide Btrfs ]

            Cette définition du wikipédia anglophone n'est donc pas conforme à la définition que j'ai donnée du CoW (qui est pourtant conforme aux explications données dans le paragraphe Copy on Write (CoW) du SysadminGuide Btrfs)…

            [ nuance conceptuelle sur le wikipédia anglophone à propos du CoW dans le stockage informatique ]

            Je précise, pour avoir lu attentivement l'article wikipédia précité, qu'il y a une nuance apportée au paragraphe concernant l'usage du CoW dans le stockage informatique. En effet, il est dit qu'il y a deux techniques pour implémenter les snapshots (je traduis) :

            1. Le stockage d'origine n'est jamais modifié — quand une requête d'écriture est faite [NDR : sous-entendu dans les données qui ont fait l'objet d'un snapshot], elle est redirigée ailleurs que dans les données d'origine, dans une nouvelle zone de stockage (c'est appelé "Redirect-on-write" ou ROW) [NDR : dans cette méthode, le snpashot pointe toujours vers le même espace de données].
            2. Quand une requête d'écriture est faite, les données sont copiées dans une nouvelle zone de stockage et alors les données d'origine sont modifiées (c'est appelé "Copy-on-write" or COW) [NDR : dans ce cas, bien que ce ne soit pas mentionné dans le texte sur Wikipédia, il faut aussi mettre à jour le snapshot pour référencer non plus la zone de stockage d'origine, mais la nouvelle zone de stockage].

            Il est ajouté ceci, qui donne la nuance (je traduis et mets la partie significative en italique) :

            Malgré leur noms, copy-on-write se réfère habituellement à la première technique. COW fait deux écritures de données, comparé à une seule écriture pour ROW ; il [NDR : sous-entendu COW] est difficile à implémenter efficacement et par conséquent utilisé peu fréquemment.

            [ ma conclusion intermédiaire, dans l'attente d'éclaircissements ]

            Il est surprenant de constater cette incohérence de définition entre le guide d'administration système pour Btrfs (une partie dédiée à Btrfs sur le wiki du site Kernel.org, à priori alimentée par des experts de Btrfs) et la page Wikipédia anglophone. Je pense que la page Wikipédia étant bien plus consultée et comportant des références, on peut lui porter crédit. J'en reste là dans l'approfondissement pour l'instant. Si quelqu'un a plus d'expertise, qu'il se manifeste.

            • [^] # Re: Quelques précisions

              Posté par . Évalué à -4 (+1/-1).

              Comme j'ai fini par le comprendre et le formuler dans un commentaire plus haut, en fait non, il n'y a pas incompatibilité entre la définition de Wikipédia et la définition tirée du SysadminGuide Btrfs…

              Désolé pour le bruit.

          • [^] # Re: Quelques précisions

            Posté par (page perso) . Évalué à 3 (+2/-0).

            La différence se joue ici : « Modifications must still create a copy » / « lorsque B est censé être modifié ». La modification peut intervenir sur A ou B, comme indiqué par Zino. Toi, tu ne parlais que d’une modification sur B.

    • [^] # Re: Quelques précisions

      Posté par (page perso) . Évalué à 2 (+0/-0).

      il n'y a pas de problème de licence

      Avec ZOL non plus. C'est l'implémentation « officielle » de ZFS sur Linux et ça passe crème au niveau licence (voir la FAQ).

  • # tout compris

    Posté par . Évalué à 3 (+2/-0). Dernière modification le 15/08/17 à 09:08.

    Enfin presque ! :)

    Il y aura un chapitre sur la récupération de données,ce genre de choses ?

    Merci

    • [^] # Re: tout compris

      Posté par . Évalué à 3 (+2/-0).

      Il y aura un chapitre sur la récupération de données,ce genre de choses ?

      Ce n'est pas prévu pour l'instant. Mais je prends note, ça peut être intéressant.

      Merci

      Avec plaisir ;-)

  • # Fragmentation: encore un problème sur SSD?

    Posté par . Évalué à 5 (+4/-0).

    Est-ce que la fragmentation est encore un problème sur les SSD, vu qu'il n'y ne devrait pas y avoir de différence pour accéder aux données, qu'elles soient physiquement proches ou éloignées (contrairement aux HD)?

    Est-que cette vision est trop naïve? Y-a-t il des benchmarks montrant au cours du temps une perte de performance de BTRFS liée à la fragmentation quand utilisés sur HD ou SSD?

    • [^] # Re: Fragmentation: encore un problème sur SSD?

      Posté par . Évalué à 7 (+5/-0).

      Je pense qu'il y a un gros mythe sur les SSD venant de la lenteur absolue dans seek HDD. Une lecture aléatoire sur un SSD reste un ou deux ordres de grandeur plus lente qu'une lecture séquentielle (Si tes blocs sont suffisamment gros, genre quelques MB, entre les seeks alors ça peut se masquer pour arriver à 25..50% de perte).

      Pas de réponse à ta question sur btrfs. Peut être que ça fragmente suffisamment peu pour qu'on puisse l'ignorer mais autrement une lecture séquentielle est toujours préférable (ça vaut aussi pour la RAM et à peu près tout).

    • [^] # Re: Fragmentation: encore un problème sur SSD?

      Posté par . Évalué à -1 (+1/-4). Dernière modification le 15/08/17 à 11:50.

      Défragmenter des fichiers sur un SSD est inutile, à part pour réduire artificiellement sa durée de vie.

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

      • [^] # Re: Fragmentation: encore un problème sur SSD?

        Posté par (page perso) . Évalué à 4 (+5/-2).

        Défragmenter des fichiers sur un SSD est inutile, à part pour réduire artificiellement sa durée de vie.

        T'as des preuves/sources pour étayer ce que tu dis ? Ou c'est une croyance personnelle ?

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

        • [^] # Re: Fragmentation: encore un problème sur SSD?

          Posté par . Évalué à 1 (+6/-7).

          T'as des preuves/sources pour étayer ce que tu dis ? Ou c'est une croyance personnelle ?

          Fait : Les SSD sont infiniment moins gênées par des données non-séquentielles, car ils ne sont pas des disques durs.
          Ce qui rend la défragmentation inutile.

          Fait : Le support de stockage utilisé par les SSD ont un nombre limité d'écritures avant d'être kapout.
          Ce qui rend la défragmentation dangereuse.

          Fait : Un contrôleur SSD essaie de gérer la durée de vie ses blocs de manière uniforme. Pour éviter que certains deviennent kapout alors que d'autres étaient "comme neufs". Donc évidemment, les données vont être fragmentées.

          Ce qui rend la défragmentation idiote.

          D'autres questions ?

          Les SSD ne sont pas en sucre.

          Ils ne sont pas non plus en bois, ni en poivre, ni en carton, ni en poudre verte, ni en gélules, ni en gel, ni en viande, ni en eau, ni…

          Mais j'avoue avoir du mal à voir le rapport entre le sucre et les SSD.

          Peux tu éclairer ma lanterne ?

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

          • [^] # Re: Fragmentation: encore un problème sur SSD?

            Posté par (page perso) . Évalué à 7 (+6/-1).

            Fait : Un contrôleur SSD essaie de gérer la durée de vie ses blocs de manière uniforme. Pour éviter que certains deviennent kapout alors que d'autres étaient "comme neufs". Donc évidemment, les données vont être fragmentées.

            Cette fragmentation n'est pas visible par le système de fichiers. Ce n'est pas la fragmentation dont on parle ici.
            De plus c'est fait uniquement par bloc entier de cellules du SSD (à ma connaissance), donc ça ne perturbe en rien les accès en lecture ou en écriture.

             

            Ce qui rend la défragmentation idiote.

            La fragmentation ne tombe pas forcément (voir même rarement ?) sur une frontière de bloc de cellules de SSD. Donc il y a une perte de temps (un peu en lecture, beaucoup en écriture), et éventuellement gaspillage de cache interne du SSD. Je n'ai jamais fait de mesure, donc je ne sais pas quantifier.

            Mais surtout beaucoup de SSD (ou même tous ?) sont bien plus lents en lecture aléatoire. Du genre 3 fois plus lents sur certaines charges, même avec des lectures alignées sur 4k (Samsung 840 pro par exemple, qui n'est pas un modèle d'entrée de gamme).
            Tu trouveras des infos à ce propos sur plein de sites de gaming.

            • [^] # Re: Fragmentation: encore un problème sur SSD?

              Posté par . Évalué à -3 (+0/-5).

              Cette fragmentation n'est pas visible par le système de fichiers

              Oui c'est ce que j'ai vu. Donc une défragmentation au niveau du FS est encore plus inutile.

              Mais surtout beaucoup de SSD (ou même tous ?) sont bien plus lents en lecture aléatoire.

              Mauvais SSD, changer SSD (ce que j'ai fait).

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

          • [^] # Re: Fragmentation: encore un problème sur SSD?

            Posté par (page perso) . Évalué à 5 (+6/-3).

            Fait : Les SSD sont infiniment moins gênées par des données non-séquentielles, car ils ne sont pas des disques durs. Ce qui rend la défragmentation inutile.

            Ton implication est fausse. La défragmentation est donc moins utile. Tout est de savoir dans quelle mesure !

            Fait : Le support de stockage utilisé par les SSD ont un nombre limité d'écritures avant d'être kapout. Ce qui rend la défragmentation dangereuse.

            Ton implication est encore fausse : pour ça, il faudrait savoir de combien elle réduit la durée de vie du SSD. Si c'est de 0,001%, on peut la considérer comme indolore.

            Fait : Un contrôleur SSD essaie de gérer la durée de vie ses blocs de manière uniforme. Pour éviter que certains deviennent kapout alors que d'autres étaient "comme neufs". Donc évidemment, les données vont être fragmentées.

            Ton implication est encore fausse. La fragmentation du SSD n'a pas lieu au même niveau.

        • [^] # Re: Fragmentation: encore un problème sur SSD?

          Posté par . Évalué à -9 (+0/-11).

          T'as des preuves/sources pour étayer ce que tu dis ? Ou c'est une croyance personnelle ?

          LinuxFR défragmente des SSD.

          Putain la honte.

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

        • [^] # Re: Fragmentation: encore un problème sur SSD?

          Posté par . Évalué à 2 (+0/-0).

          T'as des preuves/sources pour étayer ce que tu dis ? Ou c'est une croyance personnelle ?

          Source (parmi beaucoup d'autres) : https://blog.oo-software.com/en/defragmentation-and-ssds-opportunities-and-risks

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

          • [^] # Re: Fragmentation: encore un problème sur SSD?

            Posté par (page perso) . Évalué à 2 (+0/-1).

            Pourtant, le random read est clairement moins bon que du séquentiel http://ssd.userbenchmark.com/Samsung-850-Evo-250GB/Rating/2977 ou http://ssd.userbenchmark.com/Intel-520-Series-120GB/Rating/1935 C'est bien que la fragmentation n'est pas si bien que ça.

            « 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: Fragmentation: encore un problème sur SSD?

              Posté par . Évalué à 7 (+7/-1).

              Ce que tu n'as pas l'air de comprendre c'est que tu n'as pas la moindre idée de la fragmentation interne du SSD. Entre ce que pense être l'organisation des données sur le disque pour le système d'exploitation et l'organisation réelle des données dans les puces c'est complètement différents, et il n'y a aucun moyen de savoir comment c'est dans le SSD. De plus chaque contrôleur SSD aura sa propre stratégie.

              Il y a également des tas de SSD qui ont un "cache" avec de la flash SLC, et les données dans ce cache seront ensuite écrite en arrière plan dans la flash TLC. Il y a également les algo de wear leveling qui vont réorganiser en arrière plan les blocs de flash partiellement utilisés en blocs complètements utilisés (la commande trim aidant le SSD à connaitre les emplacements libres) pour avoir plus de blocs libres et de meilleurs performances en écriture dans le futur en évitant le phénomène de write amplification.

              À partir de là tu devrais commencer à comprendre que défragmenter un système de fichier sur un SSD va entrainer, d'une part une usure inutile des cellules flash, et d'autre part une désorganisation interne des blocs flash. Tout le boulot fait par le SSD pour conserver son endurance et ses performances va être saccagé par les tonnes d'écriture faite par le processus de défragmentation et consolidation du système de fichier.

              Un disque SSD ne fonctionne pas du tout comme un disque dur, et donc il ne faut surtout pas utiliser les mêmes stratégies.

              • [^] # Re: Fragmentation: encore un problème sur SSD?

                Posté par (page perso) . Évalué à 2 (+0/-1).

                Sauf que les cellules d’un SSD, elles font plus que 4k, donc si tu fragmentes ton FS, tu vas avoir plusieurs fichiers différents par cellule du SSD, et c’est ça qui va te tuer le plus les perfs. Donc, oui, la fragmentation est inévitable mais sur des blocs de taille différents que le FS.

                « 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: Fragmentation: encore un problème sur SSD?

                  Posté par . Évalué à 4 (+2/-0).

                  Question: c'est quoi la taille d'une cellule de SSD? Enfin, je veux dire, c'est de quel ordre de grandeur? Parce que du coup ça pourrait p'tet être intéressant de configurer le FS pour que la taille d'un bloc soit plus proche de la taille d'une cellule du SSD?
                  Je sais que du coup on perdrai de l'espace pour les petits fichiers (genre ceux dans /etc) mais dans le cas des fichiers de, genre, /usr/bin ou /var/cache/apt/archives, c'est moins sûr…

                  J'imagine que c'est une question bête, dans ce cas mea culpa :)

                  • [^] # Re: Fragmentation: encore un problème sur SSD?

                    Posté par (page perso) . Évalué à 3 (+0/-0).

                    Ça dépend des modèles, les pages (la plus petite quantité inscriptible/lisible) font entre 2K et 8K, les blocks (la plus petite quantité effaçable, et donc la partie qui va être balancé sur tout le disque pour répartir les écritures) font entre 512K et 8M.

                    « 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: Fragmentation: encore un problème sur SSD?

                    Posté par . Évalué à 2 (+2/-0).

                    En fait, il y a plusieurs niveau de découpage.

                    • Les pages sont la plus petite unité de donnée, entre 2Ko et 32Ko. On peut écrire ou lire une page, mais pas la modifier ou l'effacer.
                    • Les pages sont groupées en erase blocks (généralement entre 128Ko et 2Mo). Si on veut réécrire des données, il faut remplacer un erase block d'un coup.
                    • Le contrôleur du SSD travaille avec des structures encore plus grandes, les segments. Un segment fait généralement 4Mo (parfois 2Mo ou 8Mo). Il me semble que le wear leveling se fait segment par segment.

                    Note que ces infos datent d'il y a quelques années maintenant et concernent les mémoires de type NAND. Je ne suis pas sûr que les autres technologies utilisent le même principe, et les tailles ont peut-être changés.

                    Je sais que j'avais lancé des benchmarks sur une carte SD "rapide", et lire 1024 octets prenait 20 fois plus de temps si les données étaient sur deux segments, par rapport à si elles étaient alignées.

                • [^] # Re: Fragmentation: encore un problème sur SSD?

                  Posté par . Évalué à 2 (+1/-0).

                  Oui, je n'ai jamais dit l'inverse.

                  Ce qui tue les perfs en lecture c'est de balancer au SSD des tonnes d'ordres de lecture de toute petite taille. Soyons réaliste, la fragmentation d'un fichier n'est vraiment un problème que pour les gros fichiers, et les gros fichiers sont très rarement voir jamais fragmentés en morceaux de 4 kio dans tous les coins du système de fichiers. Si on en arrive là c'est que la partition est pratiquement pleine et il va y avoir beaucoup de problème bien plus important que la vitesse de lecture aléatoire de blocs de 4 kio sur le SSD.

                  En pratique qu'un gros fichier soit un peu fragmenté au niveau du système de fichier n'aura aucun conséquence visible sur les performances.

                  • [^] # Re: Fragmentation: encore un problème sur SSD?

                    Posté par (page perso) . Évalué à 5 (+2/-0).

                    Ce qui est dit depuis le début, c'est que la lecture aléatoire est plus coûteuse qu'une lecture séquentielle, sans inférer que ça avait un impact visible, juste qu'au niveau benchmark c'est très visible et donc pas forcément négligeable. Et que potentiellement, Btrfs ne fragmente pas assez pour que ça ait un impact (ce qui est sans doute dépendant des workload).

                    « 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: Fragmentation: encore un problème sur SSD?

        Posté par . Évalué à 5 (+5/-2). Dernière modification le 15/08/17 à 13:55.

        Défragmenter des fichiers sur un SSD est inutile

        OK. Donc si on va jusqu'au bout du raisonnement, tu veux dire que si aucun bloc de ton (FS|fichier) n'est séquentiel ça ne pose aucun problème ?

        Faisons un petit test sur un "vieux" SanDisk Ultra II (SDSSDHII480G) avec LVM + luks + ext4:

        $ cat seqread.fio 
        [seqread]
        rw=read
        size=4g
        directory=/xxx/fio
        
        $ fio seqread.fio 
        seqread: (g=0): rw=read, bs=4096B-4096B,4096B-4096B,4096B-4096B, ioengine=psync, iodepth=1
        fio-2.18
        Starting 1 process
        seqread: Laying out IO file(s) (1 file(s) / 4096MiB)
        Jobs: 1 (f=1): [R(1)][100.0%][r=235MiB/s,w=0KiB/s][r=60.1k,w=0 IOPS][eta 00m:00s]
        seqread: (groupid=0, jobs=1): err= 0: pid=7370: Tue Aug 15 12:58:14 2017
           read: IOPS=59.7k, BW=233MiB/s (244MB/s)(4096MiB/17586msec)
            clat (usec): min=0, max=8186, avg=16.28, stdev=123.09
             lat (usec): min=0, max=8186, avg=16.34, stdev=123.09
            clat percentiles (usec):
             |  1.00th=[    0],  5.00th=[    0], 10.00th=[    0], 20.00th=[    1],
             | 30.00th=[    1], 40.00th=[    1], 50.00th=[    1], 60.00th=[    1],
             | 70.00th=[    1], 80.00th=[    1], 90.00th=[    1], 95.00th=[    1],
             | 99.00th=[  956], 99.50th=[  988], 99.90th=[ 1020], 99.95th=[ 1064],
             | 99.99th=[ 1544]
            lat (usec) : 2=96.33%, 4=1.13%, 10=0.66%, 20=0.25%, 50=0.06%
            lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=1.32%
            lat (msec) : 2=0.24%, 4=0.01%, 10=0.01%
          cpu          : usr=4.05%, sys=9.50%, ctx=16556, majf=0, minf=9
          IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
             submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
             complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
             issued rwt: total=1048576,0,0, short=0,0,0, dropped=0,0,0
             latency   : target=0, window=0, percentile=100.00%, depth=1
        
        Run status group 0 (all jobs):
           READ: bw=233MiB/s (244MB/s), 233MiB/s-233MiB/s (244MB/s-244MB/s), io=4096MiB (4295MB), run=17586-17586msec
        
        Disk stats (read/write):
            dm-1: ios=16233/21, merge=0/0, ticks=32472/42, in_queue=32525, util=99.52%, aggrios=16433/24, aggrmerge=0/0, aggrticks=32844/42, aggrin_queue=32890, aggrutil=99.43%
            dm-0: ios=16433/24, merge=0/0, ticks=32844/42, in_queue=32890, util=99.43%, aggrios=16431/9, aggrmerge=2/15, aggrticks=24757/23, aggrin_queue=24767, aggrutil=99.43%
        
        
        $ cat randread.fio 
        [randread]
        rw=randread
        size=4g
        directory=/xxx/fio
        
        $ fio randread.fio
        randread: (g=0): rw=randread, bs=4096B-4096B,4096B-4096B,4096B-4096B, ioengine=psync, iodepth=1
        fio-2.18
        Starting 1 process
        randread: Laying out IO file(s) (1 file(s) / 4096MiB)
        Jobs: 1 (f=1): [r(1)][100.0%][r=17.5MiB/s,w=0KiB/s][r=4462,w=0 IOPS][eta 00m:00s]
        randread: (groupid=0, jobs=1): err= 0: pid=7443: Tue Aug 15 13:02:44 2017
           read: IOPS=4460, BW=17.5MiB/s (18.3MB/s)(4096MiB/235079msec)
            clat (usec): min=106, max=401746, avg=221.49, stdev=467.85
             lat (usec): min=106, max=401747, avg=221.70, stdev=467.85
            clat percentiles (usec):
             |  1.00th=[  181],  5.00th=[  185], 10.00th=[  189], 20.00th=[  201],
             | 30.00th=[  209], 40.00th=[  211], 50.00th=[  213], 60.00th=[  217],
             | 70.00th=[  221], 80.00th=[  231], 90.00th=[  247], 95.00th=[  262],
             | 99.00th=[  298], 99.50th=[  362], 99.90th=[ 1160], 99.95th=[ 2064],
             | 99.99th=[ 7136]
            lat (usec) : 250=91.39%, 500=8.33%, 750=0.11%, 1000=0.04%
            lat (msec) : 2=0.07%, 4=0.02%, 10=0.03%, 20=0.01%, 50=0.01%
            lat (msec) : 250=0.01%, 500=0.01%
          cpu          : usr=1.63%, sys=30.37%, ctx=1049367, majf=0, minf=8
          IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
             submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
             complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
             issued rwt: total=1048576,0,0, short=0,0,0, dropped=0,0,0
             latency   : target=0, window=0, percentile=100.00%, depth=1
        
        Run status group 0 (all jobs):
           READ: bw=17.5MiB/s (18.3MB/s), 17.5MiB/s-17.5MiB/s (18.3MB/s-18.3MB/s), io=4096MiB (4295MB), run=235079-235079msec
        
        Disk stats (read/write):
            dm-1: ios=1052300/5593, merge=0/0, ticks=223175/61682, in_queue=285049, util=93.76%, aggrios=1052598/5708, aggrmerge=0/0, aggrticks=221445/61682, aggrin_queue=283274, aggrutil=92.99%
            dm-0: ios=1052598/5708, merge=0/0, ticks=221445/61682, in_queue=283274, util=92.99%, aggrios=1052562/2206, aggrmerge=36/3534, aggrticks=190612/44612, aggrin_queue=234676, aggrutil=79.82%
          sdb: ios=1052562/2206, merge=36/3534, ticks=190612/44612, in_queue=234676, util=79.82%
        

        Lecture séquentielle: 244MB/s 60K IOPS
        Lecture aléatoire: 18MB/s 4K IOPS

        En fait la vraie question est comment un FS donné fragmente dans une utilisation courante / donnée ?

        Sur un FS classique tel que ext4, la fragmentation est, grosso modo, liée à l'augmentation de taille des fichiers. Si le bloc suivant n'est pas libre quand tu veux faire grossir un fichier, il faut en trouver un autre autre part. Sauf cas pathologique ça fragmente assez rarement, et on peut sûrement arriver à ton raccourci (ie. l'impact est suffisamment faible pour qu'on le néglige).

        Sur un FS basé sur du COW je serais beaucoup moins sur. Je ne connais rien à btrfs, mais je peux imaginer de nombreux cas d'écriture ou le COW mène à une très forte fragmentation. On retombe sur des lectures purement aléatoires… 10x plus lentes. Et c'est peut être aussi pour ça que btrsfs à un outil de defrag et une defrag online !

        https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation

        Tu me fais un test comparatif de perf ssd + btrfs avec et sans fragmentation ?

        à part pour réduire artificiellement sa durée de vie.

        Tu me fais un calcul au dos de l'enveloppe ou une étude réelle ? Les SSD ne sont pas en sucre.

        • [^] # Re: Fragmentation: encore un problème sur SSD?

          Posté par (page perso) . Évalué à 5 (+7/-4). Dernière modification le 15/08/17 à 14:44.

          Lecture aléatoire: 18MB/s 4K IOPS

          Corrige-moi si je me trompe, mais ton test teste les accès aléatoires, avec des IO aléatoires, et donc tu testes le coût d'un accès aléatoire, alors que ce dont il est parlé est un fichier séquentiel mais dont données sont plus aléatoires dans le SSD du fait du COW (donc c'est peu de "random" d'une, car on n'a pas pour habitude de changer 100 000 fois un même fichier).
          La, en imaginant la chose (donc aucun argument autre que ma tête), je me dis que ça n'a pas grand chose à voir avec ton test.

          Peux-tu faire une démonstration avec par exemple la lecture séquentielle (et non randread, car on cherche l'impact du COW sur une lecture séquentielle) d'un fichier de 4 Go dont 100000 (au pif, mais 100000 changements aléatoires sur un fichier sans le réécrire complètement c'est déjà un cas d'usage peu classique voir avec une sacré marge) octets à la position aléatoires ont été modifié sur un FS supportant le COW (donc 100000x 4 KB ont été "déplacé"/fragmentés, soit 10%, amis si tu veux aller à l’extrême pourquoi pas change le 1000000x pour être, au hasard près, proche de 100%)?
          (perso, je ne sais pas tester ça en moins de quelques minutes, mais suis intéressé par le résultat, par contre je sais que le randread a un impact surtout quand on n'a pas de queue mais rien de nouveau c'est testé partout lors d'un test d'un SSD; et je fantasme que lors d'un accès séquentiel sur un FS supportant le COW, le FS se ferait plaisir à détecter la demande séquentielle et ferait un autre thread qui lit en parallèle dans le cache les blocs arrivant sous peu mais déplacés, ou alors en fait le FS sait que le SSD s'en fout complet niveau perf, je ne sais pas juste suppositions)

          Bref, ne faisons pas n'importe quel test au pif, mais un test qui correspond au cas d'usage débattu, et ton test ne semble pas être proche du cas débattu (ou je ne l'ai pas compris, c'est possible aussi, mais la je demande alors de m'expliquer en quoi ça correspond alors qu'il me semble qu'on met en jeu beaucoup de couches intermédiaires qui changent tout en disant que tel truc précis a un impact).

          Tu me fais un calcul au dos de l'enveloppe ou une étude réelle ? Les SSD ne sont pas en sucre.

          Non, mais mêmes les constructeurs n'osent pas dire qu'ils sont aussi endurant que les HDD, as-tu plus de connaissances sur le sujet que les constructeurs?
          Test d'endurance SSD (oui, ça meurt un SSD plus vite si on déplace les blocs plus souvent genre si on fait des déplacements en plus comme discuté, faut pas en faire 10000 trop souvent, nombre non pris au hasard)
          Sérieusement, il y a assez eu de tests d'endurance sur les SSD et de discussions sur la quantité de blocs de réserve à mettre sur un SSD pour que ta réaction sarcastiquement sucrée sur ce sujet enlève de la crédibilité sur le reste qu'on connait moins.

  • # Fichiers souvent modifiés et fragmentation

    Posté par . Évalué à 3 (+1/-0).

    Si je comprends bien tout à tes explications concernant le COW, chaque fois qu'un fichier est modifié, la partie nouvelle est recopiée à part, et l'ancienne est ensuite supprimée (ou plutôt, n'est plus référencée) ?
    Donc, un fichier fréquemment modifié (disons, un fichier de traitement de texte ou de tableur) se retrouverait éclaté en plein de petits bouts, chacun correspondant à une sauvegarde du fichier (et oui, certains appuient sur Ctrl+S à chaque mot qu'ils tapent) ?
    Ces petits bouts recopiés ont-ils la taille d'une page du FS, ou bien juste la taille des données nouvelles (et donc les nouvelles pages du FS peuvent être très vides) ?

    • [^] # Re: Fichiers souvent modifiés et fragmentation

      Posté par . Évalué à 8 (+6/-0).

      Les traitements de texte et tableurs (en tout cas libreoffice, et d'autres aussi probablement) ne mettent pas à jour le fichier, mais enregistrent dans un nouveau fichier, puis renomment atomiquement en remplaçant l'ancien fichier. Donc pas de CoW puisque ce sont de nouveaux fichiers à chaque fois.
      Cette façon de faire évite, en cas de plantage, de se retrouver avec un fichier corrompu (la copie en cours d'enregistrement le sera probablement, mais l'ancien fichier n'aura pas encore été écrasé), mais ça ne préserve pas les droits des fichiers (en particulier si on avait le droit d'écriture sans être propriétaire du fichier).

      • [^] # Re: Fichiers souvent modifiés et fragmentation

        Posté par . Évalué à 3 (+2/-0). Dernière modification le 16/08/17 à 11:12.

        +1

        Pour avoir testé rapidement, je n'arrive pas à fragmenter avec LibreOffice et gedit.

        Par contre, pour des fichiers souvent modifiés "aléatoirement" (je pense aux vms et bases de données notamment), le CoW peut induire beaucoup de fragmentation. Cela vaut alors le coup de le désactiver. J'en parlerai dans le prochain épisode.

  • # Copy On Write et c++

    Posté par . Évalué à 7 (+5/-0).

    Juste pour info, l'exemple du copy on write pour les std::string en c++ est aujourd'hui faux sur la plupart des implémentations de la bibliothèque standard.
    Par exemple, la libstdc++ fournie par le projet GCC a changé cette implémentation lors de la sortie de gcc 5 car elle pose beaucoup de soucis de performance à cause des protections multi thread.

  • # OCFS2

    Posté par (page perso) . Évalué à 3 (+1/-0).

    peut être quelqu'un de plus cultivé que moi pourrait décrire les snapshots de OCFS2.
    pourquoi écris-je cela : parce que 1. j'ai très souvent lu Btrfs attendu pour les snapshot, 2. visiblement OCFS2 offre des snapshots depuis longtemps.

    peut être que OCFS2 pêche par d'autres aspects et que ce FS ne peut pas être par défaut,
    du coup on ne peut pas se reposer sur le FS pour les snapshot.

  • # Erreur équilibrage arbre B

    Posté par . Évalué à 2 (+1/-0).

    J'ai écrit une bêtise dans la partie arbre B.

    J'ai mis en inconvénient qu'il fallait régulièrement équilibrer l'arbre B. C'est faux. L'arbre B implémenté dans Btrfs s'équilibre tout seul.

Envoyer un commentaire

Suivre le flux des commentaires

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