Partitions ext4 : ne gaspillez plus l’espace disque !

Posté par  . Édité par ZeroHeure, Pierre Jarillon, Bruno Michel, Davy Defaud et Nils Ratusznik. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
61
23
mai
2018
Administration système

Le système de fichiers ext4 est le meilleur « par défaut » avec GNU/Linux : il est le choix par omission de l’immense majorité des distributions. Cependant, il a quelques limitations dues à ses choix techniques, qui font que l’on a vraiment avantage à affiner nos formatages de disques et clefs USB.

Journal des écritures

Par défaut depuis ext3, nous avons une sécurité pour prévenir les coupures de courant et autres interruptions brutales d’écriture : le journal. Il permet de retrouver un système de fichiers utilisable après un de ces problèmes. Bien sûr, le fichier en cours d’écriture lors de l’interruption est corrompu et devra probablement être jeté, mais le système de fichiers restera sain.

Pour gagner un peu d’espace disque, ou éviter trop d’écritures sur un média fragile comme les clefs USB, on peut désactiver cette sécurité. Bien sûr, on met en danger tout le contenu de la partition en cas d’accident, c’est donc déconseillé à ceux qui arrachent toujours les clés sans les démonter !

Comment qu’on fait ? Il faut formater en désactivant le journal :

mke2fs -t ext4 -O ^has_journal /dev/sdXN

Nombre de nœuds d’index fixe

Une limitation moins connue est le nombre de nœuds d’index (inodes) fixe. Cela veut dire qu’il faut choisir lors du formatage du disque quel est le nombre maximal de fichiers qu’il pourra contenir à la fois à l’avenir. Pour être sûr, le formatage par défaut prévoit le maximum, et cela occupe beaucoup d’espace pour les nœuds d’index. Si vous savez que votre disque n’aura que des fichiers particuliers (par exemple, des photos numériques, des films ou des MP3) vous pouvez demander beaucoup moins de nœuds d’index.

On peut voir combien de nœuds d’index sont prévus et occupés dans nos partitions montées avec la commande df -i. J’ai ainsi vu ce que mon /home gaspillait avec 95 % de nœuds d’index libres alors que l’espace disque est occupé à 85 % !

Comment qu’on fait ? Il faut formater en indiquant un nombre d’inodes, ou la taille moyenne des fichiers :

mke2fs -t ext4 -N [nombre d’inodes] /dev/sdXN

Espace réservé au super‐utilisateur

C’est un point bien plus connu, 5 % de la partition est réservée au compte super‐utilisateur root par défaut. Heureusement, ce quota est modifiable sans reformater la partition, on va donc seulement le mentionner pour être exhaustif.

Comment qu’on fait ? Il faut mettre ce quota à 0 % :

tune2fs -m 0 /dev/sdXN

Cas d’une clef USB de 1 Gio

Voici un cas pratique pour évaluer le pourcentage d’espace disque que l’on peut espérer gagner avec tous ces affinages. C’est une simple vieille clef USB de un « giga » avec un système Mageia Cauldron. Cela permet de remplacer les valeurs en Mio par Gio pour un disque d’un téraoctet, bien plus courant aujourd’hui :

  • espace physique : 962 Mio ;
  • formatage normal : 865 Mio.

Diantre ! 39 Mio soit 4 % du disque est perdu en formatant en ext4 !
Améliorons en gardant 0 % pour le super‐utilisateur et diminuant le maximum de fichiers :

  • formatage normal avec 0% pour le super‐utilisateur : 913 Mio ;
  • formatage pour des MP3 (3 Mio par nœud d’index) : 928 Mio, soit 1,5 % de gain ;
  • formatage pour au maximum (67 Mio par nœud d’index) : 928 Mio, soit pas de gain supplémentaire.

Améliorons tout ça, en supprimant le journal :

  • formatage sans journal pour des MP3 (3 Mio par nœud d’index) : 944 Mio, soit encore 1,5 % de gain supplémentaire.

Voilà, vous avez appris comment gagner de 16 Mio à 31 Mio dans un disque de 1 Gio.

Autant la suppression du journal n’est envisageable que pour les disques externes, autant la limitation des nœuds d’index ne mange pas de pain : vérifiez comme vos partitions prévoient dix fois plus de nœuds d’index que vous n’utilisez réellement…

Autres systèmes de fichiers ?

J’ai été tenté par d’autres systèmes de fichiers, pour voir. XFS utilise une technique de variation dynamique du nombre de nœuds d’index ; c’est plus souple, donc théoriquement mieux. Cependant, on gagne moins d’espace qu’avec les conseils ci‐dessus, même en gardant le journal :

  • formatage par défaut avec XFS : 926 Mio.

Btrfs n’est clairement pas fait pour gagner de l’espace :

  • formatage par défaut avec Btrfs : 849 Mio.

Aller plus loin

  • # Il y a un gros pb de markdown au milieu de l'article

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

    C'est tout.

    "There's no such thing as can't. You always have a choice." - Ken Gor

  • # sauf que btrfs est malin

    Posté par  . Évalué à 10.

    btrfs permet de stocker une fois des données identiques, et ce de façon transparente - il ne s'agit pas de hardlinks, mais d'une optimisation du stockage de données lorsqu'elles sont identiques. J'adorerais pouvoir faire cela avec ext4 (et j'avoue que c'est même l'espoir que ça arrive qui m'a fait cliquer sur ton journal, plein d'espoir !).

    Comment utiliser la déduplication btrfs

    • [^] # Re: sauf que btrfs est malin

      Posté par  . Évalué à 2.

      Comment utiliser la déduplication btrfs

      sur Ubuntu 16.04.03

      root@WhiteHouse:/home/trump# btrfs dedupe enable /media/raid1
      btrfs: unknown token 'dedupe'
      
    • [^] # Re: sauf que btrfs est malin

      Posté par  . Évalué à 4.

      Quid des performances?
      La dedup est connue pour avoir un coût très élevé, au point que c'est plutôt utilisé pour du stockage lent/froid.

      • [^] # Re: sauf que btrfs est malin

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

        J'utilise la déduplication offline avec duperemove, c'est plutôt rapide. C'est sûrement moins puissant que celle de ZFS, mais au moins, c'est accessible avec du matériel normal.

      • [^] # Re: sauf que btrfs est malin

        Posté par  . Évalué à 2.

        La dedup est connue pour avoir un coût très élevé, au point que c'est plutôt utilisé pour du stockage lent/froid.

        Ce n'est pas/plus tellement vrai. Dans les stockages industriels type NetApp (pas libre du tout) la dedup est activée par défaut sur les stockages SSD.

        Sur nos anciennes baies (SAS et SATA) la dedup tournait uniquement le week-end. On gagnait ~20-25% d'espace de stockage sans perdre de performance pendant les heures de bureau.

        Dans les deux cas on note un léger gain de performance, dans la mesure ou l'espace de cache des baies se trouve maximiser (plus de blocs en double, triple … dans le cache)

    • [^] # Re: sauf que btrfs est malin

      Posté par  (site web personnel) . Évalué à 1. Dernière modification le 09 juin 2018 à 14:17.

      Dans btrfs, il y a aussi la compression. Suivant le type de fichiers, ça peut être utile.

      Il faut aussi noter que btrfs peut décider de stocker deux fois les métadonnées (le profil "DUP") mais on peut le forcer à ne les stocker qu'une fois.

  • # taille des inodes

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

    cela occupe beaucoup d’espace pour les nœuds d’index

    On a une idée de l'espace utilisé par les inodes justement ?

    • [^] # Re: taille des inodes

      Posté par  . Évalué à 3.

      Ben il suffit de calculer : si on gagne 40Go en passant de 29M inodes à 4M, cela fait 625k inodes par Go, donc 625 inodes occupent un mégaoctet.

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

      • [^] # Re: taille des inodes

        Posté par  . Évalué à 2.

        Il me semble que la taille d'un inode est indiquée quand on utilise par exemple "dumpe2fs /dev/sdX1", et c'est pour mon disque système en ext4 :
        Inode size: 256

  • # journalisation inutile pour les file systems en read only

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

    Dans certaines installations, un file system peut être quasiment en permanence en read only. Si on a un mécanisme pour se prémunir de panes de courant lorsqu'il passe en écriture (pour une mise à jour par ex), la journalisation ne sert à rien et on peut gagner de la place dans ce cas là.
    Dans le même genre, toujours pour des file systems en read only, de la compression asymétrique peut être très intéressante. C'est consommateur en cpu/ram/temps pour la compression et presque rien pour la décompression.

  • # Espace réservé au super‐utilisateur

    Posté par  . Évalué à 7.

    Salut,

    C'est peut-être bien plus connu mais pourrais-tu quand même expliquer un peu plus à quoi ça sert et pourquoi on peut le mettre à 0 ?

    Merci.

    • [^] # Re: Espace réservé au super‐utilisateur

      Posté par  (site web personnel) . Évalué à 9. Dernière modification le 24 mai 2018 à 15:24.

      (tiré de man mke2efs)

             -m pourcentage_blocs_réservés
                    Indiquer le pourcentage de blocs du système de fichiers réservés pour le superutilisateur. Cela permet d'éviter la fragmentation et permet aux démons lancés  par le  superutilisateur,  comme syslogd(8), de continuer à fonctionner correctement après que les processus non privilégiés ne soient plus autorisés à écrire sur le système de fichiers. La valeur par défaut est de 5 %.
      
      

      Étrangement ma question en lisant l'article était de trouver des applications au fait de réserver 100% à root…

      • [^] # Re: Espace réservé au super‐utilisateur

        Posté par  . Évalué à 3.

        Donc dans le cadre d'une machine ayant plusieurs disques il n'est nécessaire d'avoir cette espace que sur un disque, non?

        • [^] # Re: Espace réservé au super‐utilisateur

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

          Non c'est utile sur toute partition où il est important, pour quelque raison que ce soit, que root puisse toujours écrire un peu quand le disque est presque plein. C'est-à-dire quasiment dans tous les cas (pour pouvoir écrire un message de log (ne serait-ce que pour prévenir que la partoche est remplie), ou un quelconque autre fichier requis pour faire le boulot de sauver les meubles après le remplissage de la partition).

          Ca doit pouvoir se désactiver en toute sécurité uniquement sur une partition dont on est sûr qu'elle ne sert qu'à du stockage de fichiers d'utilisateurs finaux et ne contient aucun répertoire "système".

      • [^] # Re: Espace réservé au super‐utilisateur

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 25 mai 2018 à 00:04.

        Étrangement ma question en lisant l'article était de trouver des applications au fait de réserver 100% à root…

        J'imagine qu'avec les droits / SUID qu'il faut on doit pouvoir mettre à disposition des fichiers à des utilisateurs, qui pourront les supprimer, mais pas les remplacer en écrivant, un truc comme ça ?

        Quant à savoir si c'est un cas intéressant : https://xkcd.com/1172/

    • [^] # Re: Espace réservé au super‐utilisateur

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

      Un des avantages c'est que si le home est complet, normalement la pc ne démarre pas.

      Alors que là on peut se connecter en root, vu qu'il lui reste de la place ça fonctionne, et don peut supprimer quelques données dans le /home de l'utilisateur

  • # Pourquoi pas ext2 ?

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

    Sur des clefs usb ou autre "petit" stockages externes, je me suis toujours interrogé sur la pertinence d'utiliser ext3 ou ext4. Alors si en plus il est préférable de désactiver le journal comme conseillé ici, pourquoi ne pas proposer tout simplement de formater en ext2 ? Parce qu'à priori, sur une clé USB, ses caractéristiques suffisent (sauf si on a des gros gros fichiers).

    • [^] # Re: Pourquoi pas ext2 ?

      Posté par  . Évalué à 5.

      Et ce sera illisible sur beaucoup de systèmes, à moins d'utiliser FAT32.

      Qui n'a justement pas de journal, pas de sécurité, et pas d'espace réservè.

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

    • [^] # Re: Pourquoi pas ext2 ?

      Posté par  . Évalué à 8.

      En fait ext4 sans journal fait quand même mieux que ext2. Il faut notamment réaliser que ext4 est un ext2 plus récent, avec plein d'améliorations en vitesse d'écriture, gestion des gros fichiers, etc autres que le journal.

      Donc non c'est pas une bonne idée ext2.

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

      • [^] # Re: Pourquoi pas ext2 ?

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

        La vitesse d'écriture, sur une clé USB, elle sera pas forcément limitée par l'implem noyau du FS hein. Pour mettre 10 fichiers max dessus il doit y avoir pas mal de cas où ext2 fera le taff. Bon évidemment personne (statistiquement) ne pourra la lire, mais bon, en ext4 encore moins.

        • [^] # Re: Pourquoi pas ext2 ?

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 09 juin 2018 à 14:21.

          Il est possible d'utiliser le driver ext4 pour gérer les partitions ext2 et ext3 (CONFIG_EXT4_USE_FOR_EXT2).

  • # Quid des autres systèmes ?

    Posté par  . Évalué à 2.

    Désolé de casser l'ambiance, mais de mon côté, tôt ou tard j'ai été confronté à du Windows donc au moment de formater une clé USB, j'en ai tenu compte… Il faudrait peut-être aussi voir de ce côté, ext2/3/4 n'étant pas reconnu (hélas).

    • [^] # Re: Quid des autres systèmes ?

      Posté par  . Évalué à 4. Dernière modification le 24 mai 2018 à 22:23.

      Cet article ne visait pas seulement les clés USB, et pas spécialement l'inter-opérabilité avec Microsoft.
      Mais puisque tu lances la discussion, NTFS est tellement plus lent que ext4 sous Linux en USB que je l'ai exclus de tous mes disques. Je n'obtiens jamais plus de 2/3 de la vitesse Ext4 en NTFS, et avec le processeur nettement plus occupé.

      FAT32 de son côté n'accepte pas de fichiers de plus de 4Go, c'est prohibitif pour mes films dès 720p…

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

      • [^] # Re: Quid des autres systèmes ?

        Posté par  . Évalué à 2.

        Pour les fichiers de plus de 4 Gio il y exFAT.

      • [^] # Re: Quid des autres systèmes ?

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

        J'ai branché sur mon RaspberryPi un disque-dur USB de 2 To rempli, rempli de musiques copiées depuis un poste Windows, dans le but d'en faire un jukebox.
        À l'origine formaté en NTFS, le driver ntfs-3g saturait le pauvre RaspberryPi en permanence, l'amenant en surchauffe et faisant baisser violemment sa réactivité (plus de 30 secondes pour se connecter dessus en SSH via le LAN).
        J'ai donc fait l'inverse : formatage en ext4, re-remplissage sans problème depuis le poste Windows à l'aide du driver Ext2Fsd. Depuis, le RaspberryPi n'a plus de soucis.

        • [^] # Re: Quid des autres systèmes ?

          Posté par  . Évalué à 3.

          Par hasard, comment gères-tu les droits uid/gid quand tu partages la clé entre des linux différents ?

          Ça m'intéresse pas mal…

          • [^] # Re: Quid des autres systèmes ?

            Posté par  . Évalué à 3.

            Il n'y a pas de linux différents, mais une gestion des comptes utilisateurs. Il suffit de donner les droits lecture/écriture à tout le monde quand tu partages la clé, et cela permettra ce que tu veux.

            Par défaut, tout nouveau dossier créé avec ntfs-3g a ces droits, rien ne t'empêche de faire le même choix avec Ext4. Mais par défaut, nos distributions préfèrent sécuriser, et les dossiers sont créés avec les droits pour l'utilisateur seulement, comme pour le dossier personnel dans /home.

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

            • [^] # Re: Quid des autres systèmes ?

              Posté par  . Évalué à 7.

              J'ai un disque externe de 2 To formaté en NTFS au cul de mon mini-PC de salon (xubuntu), j'y stocke mes enregistrements de la TNT et il est dans ce format pour que je puisse l'apporter chez des connaissances et le lire partout, même si c'est peu fréquent.

              J'avais remarqué que l'occupation CPU n'était pas négligeable, alors qu'il est encore sur un port USB 2 donc limité à 35 M/s, et j'ai un peu creusé. J'ai donc ajouté une entrée dans la fstab, en m'inspirant des valeurs issues du montage automatique, et en rajoutant le mot-clé big_writes aux options.

              Elle permet de passer les transferts de buffers de seulement 4 k (par défaut à cause de FUSE) à des buffers de 128 k, et ça joue clairement sur le CPU (un Celeron Ivy Bridge à 1,8 GHz) ; c'est indiqué dans le man de ntfs-3g. Le jour où je passe à l'USB 3 côté ordinateur je pourrai aussi voir si ça joue sur la vitesse absolue, le disque étant déjà USB 3.
              En tous cas ça permet de constater qu'ext4 est assez performant côté CPU, je crois qu'il a toujours été meilleur que les autres FS.

              • [^] # Re: Quid des autres systèmes ?

                Posté par  . Évalué à 2.

                Sous Windows, je n'ai pas ces problèmes d'usage CPU.

                J'ai pu constater moi aussi ces problèmes avec ntfs-3g, quand j'étais sous Linux.

                Mais ce n'est pas une question de FS, mais d'implémentation.

                Il faut se rappeler aussi que NTFS est vieux, la version actuelle n'a pas bougé depuis XP.

                C'est un FS qui a connu les premiers Pentium, alors bon, sous Windows c'est optimisé depuis longtemps.

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

            • [^] # Re: Quid des autres systèmes ?

              Posté par  . Évalué à 1.

              Le problème, c'est que ce n'est pas intuitif pour l'utilisateur occasionnel.

              Perso, je préfèrerais un FS qui ne gère pas du tout les permissions.

              Plutôt type UDF…

          • [^] # Re: Quid des autres systèmes ?

            Posté par  . Évalué à 3.

            Il y a quelques années je suis tombé sur ce journal : https://linuxfr.org/users/elessar/journaux/acl%C2%A0-la-solution-pour-les-media-de-transport-de-donn%C3%A9es-en-ext2

            Depuis je répète cette manip dès que j'ai un média qui ne sera partagé qu'entre des Linux (même les NAS commerciaux des potes souvent)

            Suite à cette lecture je testerais bien avec ext4 sans journal, s'il est meilleur qu'ext2 ..

    • [^] # Re: Quid des autres systèmes ?

      Posté par  . Évalué à 4.

      Il n'y a pas que Windows.

      Quasi tout ce qui peut lire depuis un système de stockage de masse via une connexion USB ne lira rien du tout si ce n'est pas en FAT32 ou NTFS, plutôt que ext/btrfs/xfs/autre fs libre.

      Liste non-exhaustive :
      - La télé
      - L'ordi du voisin
      - Le MacBook
      - Le lecteur DVD/Bluray
      - La console de jeu
      - …

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

      • [^] # Re: Quid des autres systèmes ?

        Posté par  . Évalué à 5.

        Liste non-exhaustive :
        - La télé

        Au moins une exception : les Freebox.

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

        • [^] # Re: Quid des autres systèmes ?

          Posté par  . Évalué à 7.

          J'ai été surpris de tomber sur un enregistreur TV qui stockait les enregistrements dans un disque dur externe qu'il avait formaté en ext4. C'était peut-être même la télé elle-même.

          Finalement, beaucoup d'appareils fonctionnent sous Linux. De là à ce que ext4 pour les périphériques externes soit pris en charge, il y a effectivement un pas. D'autant que la gestion des droits UNIX peut effectivement venir en travers du chemin sur périphériques externes.

          Sous Android, on peut utiliser une carte SD formaté en ext4. Sous Nougat, il fallait que je la monte en ligne de commande, sous Oreo ça a l'air d'être reconnu comme n'importe quelle carte SD classique.
          Et du coup, grâce à cette dépêche, j'ai pu constater qu'on peut lancer tune2fs -O has_journal depuis Android lui-même (en root).

          Est-ce que quelqu'un a essayé de brancher un disque dur externe formaté en ZFS sur la Play Station 4 ? :-)

      • [^] # Re: Quid des autres systèmes ?

        Posté par  . Évalué à 2.

        Ils n'ont pas de support d'UDF ?

  • # Espace libre qui varie en fonction de la taille du blockdevice

    Posté par  . Évalué à 7. Dernière modification le 25 mai 2018 à 10:27.

    La méthodologie pour vérifier l'espace libre est incomplète dans ce test sur "Cas d’une clef USB de 1 Gio".
    Ou plutôt cette phrase est incorrect : "Cela permet de remplacer les valeurs en Mio par Gio pour un disque d’un téraoctet, bien plus courant aujourd’hui"

    J'avais eu à faire le test il y a quelques mois pour cerner l'espace libre après formatage ext4.
    Si on crée un ext4 sur espace de stockage de 100MB, 1 000MB, 100 000MB, on va constater que le pourcentage d'espace libre évolue dans le bon sens…


    100MB : 7% d'espace occupé par la structure de ext4
    1 000MB : 3% d'espace occupé par la structure de ext4
    100 000MB : 1% d'espace occupé par la structure de ext4

    • [^] # Re: Espace libre qui varie en fonction de la taille du blockdevice

      Posté par  . Évalué à 4.

      Ha oui, je viens d'avoir l'idée d'essayer sur un fichier pour aller vite, et confirme que le pourcentage s'améliore. Donc mon extrapolation pour un téraoctet est fausse.

      Je viens d'essayer sur un fichier de 100Go, et j'obtiens :

      • 97,9Go par défaut
      • 98,4Go sans journal
      • 99,4Go avec le minimum d'inodes
      • 99,9Go en optimisation complète, soit 2Go de gagnés par celle-ci.

      C'est quand même plutôt 2% d'espace occupé par la structure de ext4, comment arrives-tu à 1%?

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

      • [^] # Re: Espace libre qui varie en fonction de la taille du blockdevice

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

        Du coup, tu as déduit une formule du type consommation structurelle = taille fixe + pourcentage du volume * taille du volume ? (le tout en fonction de la taille des blocs ?).

        • [^] # Re: Espace libre qui varie en fonction de la taille du blockdevice

          Posté par  . Évalué à 4. Dernière modification le 25 mai 2018 à 16:19.

          Non, je suis pas assez matheux pour ça. J'ai ce miniscript, ça ne fait pas le calcul tout seul, mais voici de quoi afficher ce que donnent les différentes options de formatage en Mo sans se fatiguer. ATTENTION, ça formate pour de vrai le périphérique/fichier indiqué en paramétre!

          #!/bin/sh
          ```for cas in "" "-O ^has_journal" "-i 67108864" "-O ^has_journal -i 67108864";
          do
                  mkfs.ext4 -m 0  $cas -F $1 >/dev/null 2>&1
                  mount $1 /mnt
                  echo --------------------------------
                  echo Cas $cas
                  df --block-size=1024K | grep mnt
                  df -i | grep mnt
                  umount /mnt
          done
          

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

      • [^] # Re: Espace libre qui varie en fonction de la taille du blockdevice

        Posté par  . Évalué à 3. Dernière modification le 25 mai 2018 à 15:51.

        Je complète avec un disque USB de 2To :

        • 1863Gio réèls
        • 1832Gio par défaut
        • 1833Gio sans journal
        • 1861Gio avec le minimum d'inodes
        • 1862Gio en optimisation complète, soit 30Gio de gagnés par celle-ci.

        Cela fait toujours 1,7% de gain…

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

  • # ext4, le meilleur "par défaut" ?

    Posté par  . Évalué à 5.

    Deux remarques.

    Sur quoi te fondes-tu pour dire que ext4 est le meilleur, sachant que tu ne parles pas des autres ?

    Xfs est le système par défaut sur CentOS/Red Hat/Fedora. L'immense majorité des distributions Linux ne se réduirait-elle pas, de ton point de vue, à Debian/Ubuntu ?

    • [^] # Re: ext4, le meilleur "par défaut" ?

      Posté par  (site web personnel) . Évalué à -10. Dernière modification le 09 juin 2018 à 18:40.

      Pour ma part je considère qu'ext4 fait partie des pires FS disponibles (ext3 étant encore pire).

      C'est souvent le problème avec les technos libres. Certaines sont décrétées "top moumoute" sans aucun argument par on ne sait qui et cet avis est répété à outrance jusqu'à ce qu'il soit partagé par un très large nombre de personne.

      Il existe un véritable manque d'objectivité dans la communauté du libre.
      Heureusement ce manque d'objectivité n'est pas systématique mais il n'empêche qu'il est inquiétant d'autant plus qu'on assiste parallèlement à des comportements qui s'approchent grandement du Théorème du singe.

    • [^] # Re: ext4, le meilleur "par défaut" ?

      Posté par  . Évalué à 3.

      Xfs n'est le système par défaut que pour les serveurs. Les stations de travail CentOS/Red Hat/Fedora continuent avec ext4. Pour ma part, j'utilise Mageia, qui fait aussi du ext4 par défaut, c'est même pas du Debian ;-)

      Mais effectivement, je postulais sans preuve. Il semblerait que xfs avance bien en ce moment, avec du online fsck en préparation pour le noyau 4.16!

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

Suivre le flux des commentaires

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