ext3 est mort ? Vive ext4 !

Posté par  . Modéré par baud123.
Étiquettes :
44
14
juin
2009
Linux
Depuis de nombreuses années (introduit dans Linux 2.4.15 en novembre 2001, pour être précis), le système de fichiers par défaut de la plupart des distributions GNU/Linux était l'ext3.

Cependant, les équipements modernes tels que les unités de stockage en masse commencent à en atteindre les limites: la gestion des données par blocs n'est plus adaptée à la taille des fichiers qui sont utilisés maintenant.

En effet, les volumes de données à traiter augmentent en permanence et dans ce contexte, le vieillissant système de fichiers ext3 commence à montrer ses limites:
taille maximum du système de fichiers de 16 To fixée par un nombre de blocs codé sur 32 bits et des blocs de données de 4KB.

Le développement de ext4 a donc débuté en novembre 2006. Deux changements fondamentaux ont été apportés par rapport à ext3:
  1. Le nombre de blocs a été augmenté, passant de 32 à 48 bits ;
  2. L'adressage indirect de bloc (i.e: les blocs représentant un fichier sont enregistrés comme une liste de blocs uniques) a été remplacé par des "extents" (i.e: des plages de blocs).
Le sommaire...

Un système de fichiers plus grand ()

ext4 fonctionne avec un nombre de blocs codé sur 48 bits. La taille par défaut d'un bloc reste inchangée (4 KB). Cela permet donc d'atteindre une taille maximale pour le système de fichiers de 1 024 Po (1 024 000 To).

La valeur des i_blocks dans les inodes (qui contient le nombre de blocs utilisé par un fichier) a été adapté d'ext3 (longueur de 32 bits) de deux manières:
  1. Il ne compte plus en unité de secteurs de 512 octets du disque dur (comme c'est le cas d'ext3) mais en unité égale à la taille de bloc du système de fichiers (4 KB par défaut) ;
  2. Deux octets de l'inode qui étaient inutilisés jusqu'à présent sont maintenant utilisés pour enregistrer les 16 bits les plus hauts du numéro de bloc codé sur 48 bits.

Concernant les autres systèmes de fichiers présents dans le noyau, le principal rival d'ext4 est XFS, dans la mesure où JFs a du mal percer et que Reiser4 n'est toujours pas intégré au noyau.

Petit comparatif :
Système de fichierTaille maximum d'un fichierTaille maximum du système de fichier
Ext416 To1024 Po
Ext32 To16 To
ReiserFS 38 To16 To
XFS8192 Po8192 Po
ZFS (Solaris)16384 Po16384 Po


De gros fichiers...place aux "extents" ()

L'amélioration la plus importante d'ext4 porte sur l'utilisation d'extents en lieu et place de l'adressage de blocs indirect (ext3).

Une inode ext3 contient les numéros d'un maximum de 12 blocs de 4 KB. Si un fichier est plus grand que 48 KB il est alors adressé en utilisant un adressage indirect simple (jusqu'à 4 MB), puis double (jusqu'à 4 GB) et enfin triple : dans ce dernier cas, un numéro de bloc dans une inode pointe vers un bloc contenant des numéros de blocs qui eux-même pointent vers des blocs contenant des numéros de blocs qui contiennent les données.

Les "extents"

Au lieu d'adresser des blocs uniques, les "extents" représentent une portion de fichier (la plus grande possible) qui correspondent à des blocs consécutifs sur le disque dur. Ainsi, au lieu de stocker une longue liste de blocs, il suffit d'enregistrer seulement trois données : le début et la taille de la portion de fichier, et le numéro du premier bloc de données sur le disque dur.

ext4 utilise 32 bits pour stocker le nombre de blocs dans un fichier, ce qui limite la taille maximum d'un fichier à 16 To. Il est envisageable de dépasser cette limite avec une évolution du format des extents.

Un "extent" (12 octets) est structuré ainsi:
  • 48 bits sont utilisés pour enregistrer le numéro du premier bloc physique ;
  • 15 bits sont utilisés pour stocker la taille de l'extent : un extent ne peut donc dépasser 128 Mo. La raison pour cela est simple : tout comme ext3, ext4 découpe le disque dur en groupes de blocs de 128 Mo ;
  • 32 bits utilisés pour stocker le numéro de bloc logique.

Les extents offrent le maximum de performance pour les fichiers très volumineux, en particulier lorsque l'on touche principalement aux méta données : lors de la suppression de fichier par exemple. La différence avec ext3 est frappante : sous ext4, la suppression est rapide comme l'éclair.

Avantages et limites ()

Avantages
  • Augmentation de la taille maximum du système de fichiers ;
  • Augmentation de la taille maximum d'un fichier ;
  • Meilleure performance pour les fichiers volumineux ;
  • Meilleure fiabilité :
    • Une somme de contrôle (checksum) a été ajoutée à chaque transaction dans le journal. Cela permet à la fois de détecter les données mal écrites dans le journal et simplifie également l'écriture des commits pour les transactions dans le journal ;
    • Les extents permettent un contrôle de cohérence plus poussé qu'avec les listes de blocs de ext3. En effet, il est possible, par exemple, de vérifier si l'extent d'un fichier dépasse sur un autre ;
    • La durée d'un fsck est réduite de manière significative. Lorsque l'on créé un système de fichiers ext4, tous les groupes de blocs ne sont pas initialisés. Ainsi, au moment de vérifier la cohérence du système de fichier, seuls les inodes initialisés ont besoins d'être parcourus.

  • ext4 permet un nombre de sous dossiers illimité ;
  • Compatibilité descendante avec ext3


Limites
  • Double adressage : la compatibilité avec ext3 permet donc de monter une partition ext3 en tant que ext4. Cependant, cela ne changera absolument rien au système. Il est possible d'activer les extents sur ce type de partitions (tune2fs -O extents). Attention, seuls les nouveaux fichiers utiliseront les nouvelles possibilité d'ext4. Un drapeau dans l'inode indique au système s'il s'agit d'un système d'adressage par liste de blocs (ext3) ou bien par extents (ext4). Migrer complètement de ext3 vers ext4 à 100% implique donc de déplacer tous les fichiers sur le disque dur ;
  • Une fois les extents activés, il n'y a pas de méthode facile pour revenir à ext3 ;
  • En cas de problème sur le système, il faut prendre la précaution d'utiliser un système de sauvetage qui supporte l'ext4

Aller plus loin

  • # Super !

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

    Super article ! Au moins, on sait ce que sont les extents maintenant !

    Petit problème cependant à la ligne :
    ReiserFS 3 8 Tbyte 6 Tbyte

    Vous vouliez dire 16 à la place de 6 ?

    Voilà, encore merci
    • [^] # Re: Super !

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

      Vous vouliez dire 16 à la place de 6 ?

      bien vu, j'ai corrigé. J'avais aussi failli mettre des Tio, Pio à la place de Tbyte, Pbyte mais bon...

      Pour les extents (et le reste), la conf' ext4 au FOSDEM cette année de Theodore_Ts%27o était particulièrement intéressante.
      • [^] # Re: Super !

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

        Reste une faute de frappe : 1384 au lieu de 16384.

        Et une curiosité : dans l'article tu parles de JFS, et juste dans le tableau qui suit, tu ne le compares pas aux autres (mais tu présentes ZFS, dont tu n'avais pas parlé).
  • # Et pour les nombreux petits fichiers

    Posté par  . Évalué à 10.

    Bravo au rédacteur.
    Mais, il manque une information, quel est l'impact sur les nombreux petit fichier?
  • # Le futur: btrfs

    Posté par  . Évalué à 2.

    Merci pour cette belle synthèse.

    Toutefois, il me semble important de préciser qu'ext4 n'est qu'un FS de transition en attendant la disponibilité de btrfs.
    • [^] # Re: Le futur: btrfs

      Posté par  . Évalué à 10.

      hum, une transition qui pourrait bien durer plusieurs années, et déboucher sur autre chose que btrfs (peut-être ZFS après un changement de licence d'Oracle ?).
  • # XFS et grosse partition

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

    Sur les grosses partitions, je suis sous XFS comme toutes les personnes qui m'entoure. Ext3 est fatal avec son temps de création TRES long et son checkdisk beaucoup trop long...

    Qui a déjà utilisé Ext4 sur des partitions de plus de 10To et quel est l'avantage par rapport a XFS qui domine ce segment depuis plusieurs années maintenant ?
  • # Linux magazine?

    Posté par  . Évalué à 4.

    Il me semble avoir lu quasi le même article dans linux magazine; c'est moi, ou bien j'ai fumé?
  • # Juste une question

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

    J'aurais seulement une petite question à laquelle le (très intéressant) article ne répond pas.

    Est-ce utilisable en production aujourd'hui ? Quelle version du noyau au minimum ?

    Avant de l'utiliser sur un FS de quelques To, j'aimerais autant avoir l'un ou l'autre retour :-)
    • [^] # Re: Juste une question

      Posté par  . Évalué à 3.

      Ext4 est devenu officiellement utilisable en prod' à partir du noyau 2.6.28, si j'en crois sa page Wikipedia
      • [^] # Re: Juste une question

        Posté par  . Évalué à 3.

        Moi je te conseille d'attendre encore quelques versions de noyau. Rien que dans le dernier noyau (2.6.30), un comportement gênant (voire critique) a été corrigé, il te faisait perdre le contenu de certains fichiers dans certaines situations. Voir la dépêche de patrick_g pour plus d'info.
      • [^] # Re: Juste une question

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

        Quand je suis passé à la dernière version d'Ubuntu, je me suis dit "youpi, je vais pouvoir passer à ext4, mes checkdisks prennent des plombes".
        J'ai commencé à monter mes volumes ext3 en ext4 (donc sans les options qui permettent d'utiliser les extents, dans un premier temps). Et puis après un moment, paf, crash. Je redémarre, j'utilise un peu ma machine, et crash. Pas d'info intéressante dans syslog.
        En remontant tous mes volumes en ext3, plus de crash aléatoire. Donc finalement j'attends un peu.
  • # Quid du resize à chaud ?

    Posté par  . Évalué à 4.

    Sur mon serveur avec RAID et LVM, j'ai voulut testé l'ext4. J'ai donc créé des partitions de 500Go que j'ai formaté en ext4. Tout allait bien. J'ai rempli la partition, et j'avais besoin de 100Go de plus.

    Pas de problème, je lance lvextend -L+100G /dev/vg0/mon_gros_device puis resize2fs /dev/vg0/mon_gros_device.

    Et là, c'est le drame. OOPS en pagaille. Obligé de démonter la partition, lancer plusieurs fsck avant de pouvoir remonter. Et la partition inchangé. Pour la resize, je suis obligé de faire le resize2fs avec la partition démonté. Avec ext3 ou reiserfs, j'ai aucun problème.

    Était-ce une version des ext-tools qui était obsolète, ou mon support noyau pas assez à jour? Quoi qu'il en soit, j'ai lâché l'affaire avec ext4. J'attendrai btrfs pour le gros changement à mon avis.

    Est-ce que d'autres ont eu le même problème que moi ? Pour des grosse partitions contenant principalement des fichiers de 700 Mo environ, vous conseillez quoi ? J'ai cru voir XFS dans un commentaire, certains ont des retours d'expérience ?
    • [^] # Re: Quid du resize à chaud ?

      Posté par  . Évalué à 10.

      Pour des grosse partitions contenant principalement des fichiers de 700 Mo environ, vous conseillez quoi ?

      Rhooo... hadopi_fs, bien sur !
    • [^] # Re: Quid du resize à chaud ?

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

      Je te conseille du xfs pour ces gros fichiers.

      Par contre évite de mettre ton /home dessus, car xfs en cas de crash hard ou violent perd le contenu des fichiers en cours d'écriture.

      Donc par exemple tu risques de perdre les fichiers qui contiennent tes onglets kde/firefox/etc...

      Pour les gros fichiers ça pose pas de soucis, tu perds juste le contenu touché depuis de début de l'écriture.

      Typiquement durant le téléchargement d'une iso mandriva tu vas perdre le bloc en cours d'écriture.

      J'utilise ça depuis 2004, ça marche très bien, mes seuls soucis ont été avec un kernel 2.6.17 qui pliait le XFS sous forte charge et dans la rc7 du 2.6.30 qui faisait du segfault, mais la rc8 et + ont corrigé tout ça.

      L'autre avantage est le fsck à chaud, tu montes la partition, quand il a fini de la monté c'est prêt ;)

      Et un xfs_fsr -v /pt_de_montage pour défragmenter si tu a beaucoup téléchargé d'iso de distribution en torrent en parallèle sur un disque plein à 80%.
      • [^] # Re: Quid du resize à chaud ?

        Posté par  . Évalué à 1.

        Donc par exemple tu risques de perdre les fichiers qui contiennent tes onglets kde/firefox/etc...

        C'est dommage de perdre de si bons onglets alors qu'on pourrait les manger.
        (mais peut-être que c'est XFS qui les mange, du coup ?)
  • # Et sinon, pour les utilisateurs normaux ?

    Posté par  . Évalué à 6.

    Dans la liste des avantages cités, je ne vois que 2 choses dont je pourrais bénéficier: le check plus rapide, et les sommes de contrôle.

    Pour tout le reste, comme les mots Tera et Peta ne font pas partie de mon vocabulaire, j'ai du mal à voir comment ça va améliorer le fonctionnement de ma machine.

    Pourquoi tous les efforts d'amélioration du FS par défaut de Linux ont été dirigés quasi-uniquement vers la gestion des "gros" volumes (c'est un euphémisme!), alors qu'une orientation performance pour des volumes moyens, voire petits (avec la généralisation des SSD) seraient bien plus utile pour l'immense majorité des utilisateurs ?

    (Je ne dis pas qu'Ext4 est inutile... mais il répond à des besoins bien particuliers, je trouve !)
    • [^] # Après les Giga, les Tera

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

      Pour tout le reste, comme les mots Tera et Peta ne font pas partie de mon vocabulaire

      Pour information, un disque dur d'un Tera se trouve à 70€, 2 Tera à 270€.
      Ca existe, ce n'est pas cher, il va falloir mettre ce mot dans ton vocabulaire...
      • [^] # Re: Après les Giga, les Tera

        Posté par  . Évalué à 2.

        Je pense qu'il dit ça car il n'en n'a pas l'usage. Si j'achète un DD d'1 To, c'est pour le laisser au 3/4 vide, ça sert à rien.

        « 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: Après les Giga, les Tera

          Posté par  . Évalué à 1.

          Anéfé, je dispose de 320 Go dont j'utilise à peine un quart… et encore j'ai 3 OS avec leurs partitions système de 10 Go chacune…

          Même si le Téra est à portée du grand public, je reporte Zenitram au texte de l'article, où il est bien mentionné que Ext3 gère déjà des volumes de 16 Po !
        • [^] # Re: Après les Giga, les Tera

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

          une propriété interessante des disques durs est que quelque soit leur taille, il finissent progressivement par se remplir de diverses conneries:
          t'as un disque de 40Go ? au bout d'un an il est plein
          t'as un disque de 1To ? au bout d'un an il sera plein
          • [^] # Re: Après les Giga, les Tera

            Posté par  . Évalué à -5.

            Arrête de tipiaker batman 42 et des logiciels de musique
            • [^] # Re: Après les Giga, les Tera

              Posté par  . Évalué à 4.

              sans aller jusqu'à tipiaker...

              au hasard des photos (de plus en plus grosses, de plus en plus nombreuses)
              Des films de vacances.
              Des enregistrement de films (bah oui le dongle DVB-T USB compatible linux c'est pas pour rien non plus) sans oublier l'enregistrement de la télé par free.

              Ça peut aussi être du téléchargement sur jamendo, nos propres enregistrement de musique (ou de massacre de musique)

              Enfin bref, un disque ça se remplit toujours on ne sais pas pourquoi...

              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Et sinon, pour les utilisateurs normaux ?

      Posté par  . Évalué à 5.

      La gestion des gros fichiers est sans doute pas mal pour celui qui manipule des films ou de la musique non compressée.

      Sur le wiki de ext4 ¹ ils parlent aussi de préallocation au niveau du système de fichier et d'allocation différée qui doivent normalement améliorer la vie de tous les jours.

      [1] http://ext4.wiki.kernel.org/index.php/Ext4_Howto
    • [^] # Re: Et sinon, pour les utilisateurs normaux ?

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

      Dans la liste des avantages cités, je ne vois que 2 choses dont je pourrais bénéficier: le check plus rapide, et les sommes de contrôle.

      Les extends sont très bénéfiques en vitesse de lectures de gros fichiers (un avi de 650 Mo ? non, une ISO Debian de 5 Go bien sûr !). Je pense qu'ils sont également bénéfiques en vitesse d'écriture (pour les disques utilisant des têtes de lecture, car ext4 en limite le déplacement).
    • [^] # Re: Et sinon, pour les utilisateurs normaux ?

      Posté par  . Évalué à 4.

      sur mes machines à moi que j'ai, en utilisant le nouveau driver ext4 sans changer quoi que ce soit au système de fichier ext3, le gain de performances est d'environ 20% pour se promener dans les structures du FS (ls, find), et autour de 40% pour les partitions complètement migrées à ext4. Testé sur un noyo 2.6.28.
    • [^] # Re: Et sinon, pour les utilisateurs normaux ?

      Posté par  . Évalué à 1.

      Si l'on en croit Phoronix et que je comprends bien leurs schémas, pour les utilisateurs "normaux", les performances d'ext4 peuvent aussi être intéressantes :

      1) pour la copie de fichiers volumineux
      2) pour le démarrage : le système aurait en effet tendance à charger plus rapidement

      Par contre, il semblerait qu'en utilisation classique - 3 - , les gains face à ext3 restent faibles voire inexistants. Bref, il ne s'agit vraisemblablement pas d'une révolution mais d'une sympathique évolution.

      Sources :
      1. http://www.phoronix.com/scan.php?page=article&item=ext4_(...) & http://www.phoronix.com/scan.php?page=article&item=btrfs(...)
      2. http://izanbardprince.wordpress.com/2009/03/28/comparing-boo(...)
      3. http://www.phoronix.com/scan.php?page=article&item=ext4_(...) et suivantes ou plus récemment, http://www.phoronix.com/scan.php?page=article&item=btrfs(...)
  • # linux v2.0

    Posté par  . Évalué à 3.

    Salut les gens!

    Je suis bien content de voir un vieux système réécrit depuis zéro... J'ai toujours l'impression qu'un bon logiciel doit bien être réécrit 2 fois pour combler les imperfections des version 1.0.

    Et je remarque que la tendance actuelle est la Grande Réécriture. Pour l'exemple et le désordre : KDE4, EXT4, IPV6... (toi aussi chez toi, cherche un gros logiciel/protocole/format réécrit!). On pourra aussi penser à Gougel Wave qui voudrait réinventer le courriel.

    Je trouve que ça fait du bien d'avoir un bon nettoyage de printemps! car j'avais un ressenti de stagnation depuis quelques années (bon ya eut compiz et ca roxe des ours!).

    Mais ce n'est qu'un ressenti, je n'ai aucun chiffre à l'appui...

    A quand une grande réécriture d'un kernel?
    • [^] # Re: linux v2.0

      Posté par  . Évalué à 5.

      Pour la réécriture du kernel, n'est-ce pas déjà le cas, avec la branche 2.6 (par rapport à la 2.4) ? Ou plus généralement la branche 2.x (qui ajoute une plus grande modularité, me semble-t-il) par rapport à la branche 1.x ?

      Parce qu'il faudrait pas se lancer dans une réécriture, juste pour dire qu'on fait une réécriture, mais parce que cela a un intérêt (tout remettre à plat et repartir sur des bases saines)...
    • [^] # Re: linux v2.0

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

      Ext4 n'est pas du tout une grande réécriture de Ext3, c'est une amélioration incrémentale.

      Les grandes réécritures c'est dangereux, y'a qu'à voir le temps qu'IPv6 et KDE 4 mettent pour sortir quelque chose capable de remplacer leurs prédécesseurs.
      • [^] # Re: linux v2.0

        Posté par  . Évalué à 4.

        Les grandes réécritures c'est dangereux, y'a qu'à voir le temps qu'IPv6 et KDE 4 mettent pour sortir quelque chose capable de remplacer leurs prédécesseurs.

        Oui, mais Perl 6 rendra les réécritures plus efficaces.
  • # Shake it, baby !

    Posté par  . Évalué à 7.

    Il y a quelques temps, un étudiant malin avait fait un programme simple de dé-fragmentation pour linux, car, malgré tout, les fichiers se fragmentent avec le temps.

    Mais là où réside l'astuce, c'est que le programme se contente de simplement bouger les fichiers du disque, profitant ainsi des algorithmes de dé-fragmentation déjà présents dans la gestion du système de fichier en cours. Il ne s'agit donc pas d'un programme de dé-fragmentation en tant que tel, mais plutôt d'un programme de copie de fichier récursive.

    Avantage : c'est compatible avec n'importe quel système de fichier, car, en gros, ce programme se contente de déplacer les fichiers du disque.
    Il convient cependant d'utiliser avec prudence, car je me rappelle d'avoir lu des rapports de premiers tests où des malheureux s'étaient essayé à «shaker» l'ensemble de leur disque et avaient rencontré des problèmes sérieux au moment ou la glibc était secouée. C'est qu'elle n'aime pas être secouée, la glibc (on la comprend).

    Pour passer massivement un système de fichier d'ext3 en ext4, vu qu'il s'agit de ré-écrire le fichier pour qu'il migre tout seul d'ext3 en ext4 si on avait auparavant une partition ext3, voici une nouvelle application inattendue pour ce programme, non ?

    Voici le lien freshmeat
    [http://freshmeat.net/projects/shake]
  • # ext4FS vs btrFS

    Posté par  . Évalué à 1.

    Visiblement ext4fs sera un fs 'temporaire' le but étant qu'il soit remplacé à terme par btrfs.

    Je ne comprends pas cette optique de développer un système en se disant à priori qu'il ne durera qu'un temps ?

    Pourquoi ne pas avoir choisi d'essayer d'implémenter un FS pérenne tel que ZFS (si tant est qu'il existe un système pérenne car ce qui semble largement suffisant aujourd'hui se révèle souvent être limité qlqs années après...) ?
    • [^] # Re: ext4FS vs btrFS

      Posté par  . Évalué à 4.

      En informatique tout ne dure qu'un temps...
      Si tu attends d'avoir le truc ultime tu ne sortiras jamais rien.
      • [^] # Re: ext4FS vs btrFS

        Posté par  . Évalué à 1.

        ce n'était pas le sens de ma question ;
        je sais bien que tt ne dure qu'un temps mais certains FS sont designés dès le début pr durer le plus lgtemps possble c'est le cas de ZFS

        Alors que la avec ext4fs on sait déjà que ce FS a des limitations par rapport aux autres FS existants.
    • [^] # Re: ext4FS vs btrFS

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

      Ils n'ont pas « développé un système », ils ont amélioré l'existant. C'est une amélioration incrémentale, pas un nouveau filesystem écrit à partir de zéro pour révolutionner le monde. C'était entre guillemets rapide et facile à faire, par rapport à de vrais nouveaux développements, et ça fait avancer les choses en attendant la relève.
  • # Unités…

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

    Y a que moi que ça choque de voir écrire 1 Po = 1 024 000 To ?

    Récemment il y a eu une renormalisation de l'écriture des multiples, elle a le mérite de lever pas mal d'ambigüités… Cf http://fr.wikipedia.org/wiki/Préfixe_binaire

    Ainsi, 1 To (téraoctet) = 10¹² octets, mais 1 Tio (tébioctet) = 2⁴⁰ octets…

    Donc 1 Pio (pébioctet) = 1 024 Tio, et 1 Po (péraoctet) = 1 000 To.
    • [^] # Re: Unités…

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

      Y a que moi que ça choque de voir écrire 1 Po = 1 024 000 To ?

      Non, car c'est complètement faux. 1 Po = 1024 To. (Et c'est petaoctet, pas peraoctet.)

      Quand à la normalisation des multiples puissances de 2, elle aurait mieux fait de ne pas utiliser des noms aux sonorités ridicules. Je limite son usage aux contextes où l'ambiguïté n'est pas de mise.

Suivre le flux des commentaires

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