Journal Choix d'un système de fichiers

Posté par  .
Étiquettes : aucune
0
14
fév.
2007
Bonjour,

D'après un certain nombre d'articles que j'ai pu lire, il apparaît que XFS est bien plus performant que ext3.

http://www.bullopensource.org/ext4 ici quand ils parlent de ext3 + patches, il s'agit du futur ext4, ne pas confondre avec ext3

Or, beaucoup de distribs majeures proposent ext3 par défaut. kernel.org est en ext3...

Y'a des gens qui ont des infos ?

  • # Linux mag 90

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

    Dans le linux mag 90 y a un article des gens de Bull sur ext4 et sur les perf de ext3 je me souviens plus des résultat mais tu peut peut-être te le procurer.

  • # avis tout personnel

    Posté par  . Évalué à 5.

    J'ai tente XFS et bon c'est peut etre super efficace mais ca resiste pas bien si matos un peu pourri... En gros j'avais un portable avec un disque dur qui trouvat drole de perdre la connection physique avec la carte mere... XFS a pas du tout aime, ext3 non plus mais au moins il m'a pas perdu les donnees.
    C'est d'ailleurs marque dans la doc de XFS ce genre de petits details mais je ne me doutais pas que 1) le portable tout neuf aurait ce probleme 2) que les mecs de HP seraient assez incompetant pour identifier 3 fois ce probleme au fait que c'etait un linux installe (alors que le bios ne voyait pas le disque en question).

    Un autre avantage de ext3 c'est que si tu as une partition windows tu peux y acceder ce qui n'est pas le cas (je crois) avec une partition xfs, jfs, reiserfs ou autre.

    Perso le meilleur compromis que j'ai trouve c'est le ext3 mais bon j'espere qu'ils vont faire ce qu'ils ont dit pour ext4 et il me tarde la possibilite de pouvoir stoper un fsck en plein milieu (c'est pas hyper cool sur un portable lorsque tu n'as que la batterie) par exemple.

    • [^] # Re: avis tout personnel

      Posté par  . Évalué à 4.

      YAReG permet de lire du ReiserFS depuis Windows. Mais j'ai jamais teste (je tourne en ext3 chez moi)

      http://yareg.akucom.de/

      • [^] # Re: avis tout personnel

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

        Pour avoir testé rfstool dont YAReg est une GUI je peux dire que ce n'est pas encore parfaitement stable. J'ai testé avec un disque dur de 200Go contenant notamment 60-70 sous dossiers dans un dossier a la racine du disque dur et dès que j'essaie d'y accédé j'ai un plantage monstrueux de l'ordinateur.
        Bref très bonne initiative mais comme le driver NTFS pour linux, rfstool nécessite encore un peu de travail pour être utilisable.

    • [^] # Re: avis tout personnel

      Posté par  . Évalué à 5.

      C'est aussi un problème de ReiserFS. J'ai déjà perdu mon / entier à cause de ce FS.

      Du coup je suis sous ext3, mais il rame ce truc, c'est assez lourd.

      • [^] # Re: avis tout personnel

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

        Je confirme, j'ai aussi perdus une partition sous ReiserFS alors que les autres partoches ext3 n'ont rien eut...

        Depuis je suis sous ext3 ... alors que je prêchais le ReiserFS...

      • [^] # Re: avis tout personnel

        Posté par  . Évalué à 2.

        Pareil pour moi, je ne conseille plus reiserfs depuis que j'ai perdu les 3/4 des fichiers d'une partition, suite à un agrandissement avec parted.

        J'ai fait la même manipulation avec ext3, sans aucun soucis.

      • [^] # Re: avis tout personnel

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

        Perso, j'ai juste perdu des fichiers suite à coupure secteur pendant des transferts ('ma faute, j'aurais dû annuler le transfert, mais je me suis dit "Mais si, l'onduleur va bien tenir encore une minute...").

        Ben non.
        RAS sur l'ext3.

    • [^] # Re: avis tout personnel

      Posté par  . Évalué à 5.

      connection/connexion
      C'est dingue cette manie de l'écrire en anglais... :)

  • # ext3 pour le meilleur et pour le pire (les perfs sur des ptits fichiers)

    Posté par  . Évalué à 7.

    il n'y a pas que les performances qui comptent comme critère il y a aussi la fiabilité, cela étant dit ca ne veut pas forcement dire que xfs est moins fiable que ext3.
    En tout cas ext2/3 est nettement plus utilisé, il y a donc beaucoup de retour et positifs de sucroît, on en arrive donc au critère de réputation.

  • # Ne pas se prendre la tête

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

    Le système de fichiers ext3 (ext2) est celui de base dans le kernel vanilla, et par voie de conséquence dans quasiment toutes les distros majeures, en choisir un autre n'apporte pas forcément de gains, mais souvent des désagréments, àmha ne pas se prendre la tête...

    • [^] # Re: Ne pas se prendre la tête

      Posté par  . Évalué à 4.

      Je suis d'accord. ext2/3 conviennent pour tous les usages courants, ont fait leur preuves, sont bien connus, et offrent des performances correctes dans tous les domaines et aussi une fiabilité qui est éprouvée. Ça en a fait le système de fichiers par défaut de toute distribution grand public, car il convient à tous les usages "courants".

      Il n'y a que pour certains cas "extrêmes" que l'usage d'un autre FS peut devenir intéressant (par rapport aux problèmes qui vont avec, les autres FS ne bénéficiant pour l'instant pas des mêmes qualités). Je pense notamment aux serveurs très fortement chargés, aux très grosses bases de données, aux spiders et tout autre système qui est à la fois
      - très fortement sollicité
      et
      - réservé à un usage applicatif précis faisant un usage intensif des accès disques (partage de fichiers ?).

      • [^] # Re: Ne pas se prendre la tête

        Posté par  . Évalué à 7.

        > Je suis d'accord. ext2/3 conviennent pour tous les usages courants

        Comme tout les FS...

        > Il n'y a que pour certains cas "extrêmes" que l'usage d'un autre FS peut devenir intéressant
        > Je pense notamment aux serveurs très fortement chargés

        Là tu te trompes un peu. Le point fort d'ext3 n'est pas un usage Desktop, c'est en usage serveur avec forte charge qu'il donne toute sa mesure (lecture et écriture simultannées). C'est pour ça que Red Hat l'utilise. Pour un serveur de fichier ou base de donnée sous forte charge et sur un système multi-cpu, les autres FS se prennent une branlée. Et c'est aussi pour ça que Novell a laissé tomber ReiserFS.
        Autre point positif d'ext3, il supporte tout sans accro : ACL, SeLinux, NFS, Smb, etc...

        Les gros problèmes actuels d'ext3 sont la limite en taille (8 ou 16 To) et la durée des fsck. Ces problèmes seront corrigés avec ext4. Notes bien que ces problèmes ne consernent pas un usage courant/desktop. Mais ils sont tout en haut de la TODO list.

        • [^] # Re: Ne pas se prendre la tête

          Posté par  . Évalué à 2.

          un portable etant generalement fait pour faire du desktop, je trouve le probleme du fsck tout a fait adapter dans ce cas la comme je l'ai indique plus bas (enfin j'ai juste mis la possibilite de pouvoir l'interompre mais si il est rapide ca me va aussi)

  • # No comment...

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

    Oui, XFS j'ai tenté.
    http://linuxfr.org/~liberf0rce/14634.html
    http://linuxfr.org/~liberf0rce/20108.html

    Et puis après de nombreux problèmes, plus le fait que le kernel 2.6.17 est buggé jusqu'à l'os pour XFS (et que c'est le kernel par défaut de la mandriva 2007), j'ai saisi l'occasion pour migrer vers EXT3. Cela fait 3 mois maintenant, et je ne regrette pas.

    Un lien vu à l'époque:
    http://www.gentoo.org/doc/en/articles/afig-ct-ext3-intro.xml

    Interestingly, ext3 handles journaling very differently than ReiserFS and other journaling filesystems do. With ReiserFS, XFS, and JFS, the filesystem driver journals metadata, but makes no provisions for journaling data. With metadata-only journaling, your filesystem metadata is going to be rock solid, and you will probably never need to perform an exhaustive fsck. However, unexpected reboots and system lock-ups can result in significant corruption of recently-modified data. Ext3 uses a couple of innovative solutions to avoid these problems, which we'll look at in a bit.


    Donc XFS c'est bien pour avoir un filesystem robuste (contre la corruption du filesystem) et rapide. Par contre pour la perte/corruption des données (et pas juste des métadonnées) c'est une autre paire de manches... J'en ai fait les frais.

    • [^] # Re: No comment...

      Posté par  . Évalué à 6.

      Tu fais bien de le souligner. Ext3 protège les données comme aucun FS le fait. C'est pour ça que c'est le "chouchou" des développeurs Linux (et de très loins). Donc les comparaisons entre ext3 et un autre système de fichier journalisé ne sont pas juste. Ext3 en fait plus et oui ça a un coût en performance (sauf sous forte charge et avec multi-cpu ou ext3 est au top).
      Mais qu'es-ce qui compte le plus ? Vitesse ou fiabilité ? Pour moi c'est la fiabilité.

      J'ai jamais compris pourquoi les gens veulent autre chose qu'ext3 alors que ce FS roxe. Certe d'autres FS font mieux dans tel ou tel domaine. Mais ext3 a un fabuleux compromis fiabilité/performance/fonctionnalité.

      • [^] # Re: No comment...

        Posté par  . Évalué à 1.

        tu veux dire qu'il met des checksums dans les métadonnées pour éviter les corruptions silencieuses ? \o/

        • [^] # Re: No comment...

          Posté par  . Évalué à 1.

          Ce type de truc est a faire par device-mapper ou raid5. Pas par le FS. Pour info, ZFS ne fait pas que système de fichier. Il fait dm/lvm/fs

      • [^] # Re: No comment...

        Posté par  . Évalué à 1.

        A cause des fsck, justement.
        Il m'arrive régulièrement d'allumer mon PC dans l'urgence pour vérifier une adresse ou un horaire.

        Sur un desktop qui n'est pas allumé en permanence, je trouve que les long fsck sont éliminatoires.

        En tout cas, je trouve que c'est plus ennuyeux que risquer de perdre les dernières modifs d'un fichier, voire même le fichier entier, vu que tout fichier important est dupliqué.

        • [^] # Re: No comment...

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

          Ah, tu éteins parfois ton pc ... donc ext3 n'est peut-etre pas le top pour le desktop finalement !

        • [^] # Re: No comment...

          Posté par  . Évalué à 2.

          tu sais que tu peux désactiver les fsck automatiques dans le fstab ?

      • [^] # Re: No comment...

        Posté par  . Évalué à 2.

        > Ext3 en fait plus et oui ça a un coût en performance

        Oui, enfin, il faut le spécifier avec l'option data=journal de mount (ou via tune2fs), sinon il ne fait que la journalisation des méta-données comme les autres. Et du coup, il n'a pas trop à rougir question performance.

  • # Mes benchs à moi

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

    J'ai benché tous les systèmes de fichiers (sauf ext4, reiser4 et zfs) sour plein de matos différents.

    Mes conclusions :
    ext3 avec data=ordered est très performants et est le meilleur compromis.

    XFS est une grosse daube imonde sur tous les matos que j'ai eu entre les mains.

    Une partie de mes résultats avec bonnie++ sur une machine identique.
    http://redfox.redfoxcenter.org/benchs/

    ENsuite, quand à savoir si il vaut mieux un systèmes de fichiers optimisé pour les gros fichiers ou pour les petits fichiers, voilà les stats d'utilisation de ma machine :

    Intervalle de taille Somme de la taille des fichiers % du total Fichiers % des fichiers
    Plus de 1 Go 3,0 Go 4,2% 1 0,0%
    256 Mo - 1 Go 25,9 Go 36,3% 43 0,0%
    64 Mo - 256 Mo 5,6 Go 7,8% 47 0,0%
    16 Mo - 64 Mo 8,6 Go 12,0% 320 0,0%
    4 Mo - 16 Mo 8,8 Go 12,3% 1 193 0,2%
    1 Mo - 4 Mo 7,9 Go 11,1% 4 521 0,7%
    256 Ko - 1 Mo 6,1 Go 8,6% 11 989 1,7%
    64 Ko - 256 Ko 2,6 Go 3,6% 21 561 3,1%
    16 Ko - 64 Ko 1,6 Go 2,3% 55 145 8,0%
    4 Ko - 16 Ko 839,6 Mo 1,1% 104 694 15,1%
    1 Ko - 4 Ko 326,3 Mo 0,4% 160 726 23,2%
    0 Ko - 1 Ko 107,0 Mo 0,1% 332 243 48,0%
    Total 71,4 Go 100,0% 692 483 100,0%

    • [^] # Re: Mes benchs à moi

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

      Tu fais une monstrueuse erreur en disant que le XFS est une daube immonde...

      Premièrement, le redémarrage de ton système est instantané, pas de fsck a faire dessus...

      Ensuite as-tu réellement regardé l'usabilité du système lors de ton filesystème sous forte charge ?

      Penons mon cas, j'ai des partitions loopback chiffrée en aes2048 (du a des lois injustes passée au parlement, bref je peux plus revenir en arrière faute de place...).

      Là dessus j'avais fait des tests (avec carte nvidia qui me freezais le pc aléatoirement).

      Le jfs était nickel, mais je l'ai dégagé pour des raisons de perfs :
      - le cpu passait a 100%
      - je pouvais plus rien faire pendant 5minutes en attendant que les données soient sync sur le disque

      Le ext3 a été dégagé pour d'autre raison :
      - perte de donnée
      - corruption totale d'une partiton de 67Go !
      (alors que je faisais des sync régulier pour l'éviter et aucune freeze lors de ces sync)
      - mauvais sur les gros fichiers (me bouffe 2% de plus que le fs de place dispo)

      Le reiserfs a pas été choisi (trop jeune, pas adapté aux grands fichiers).

      Le xfs a été choisi :
      - pas de perte de données lors de freeze (même pendant le sync, au pire tu perd juste les dernières operations, mais on s'en tape)
      - pas de fsck de 3h, tu remonte et paf c'est finis
      - très bon sur les gros fichiers de 700-1Go
      - plus faible empreinte sur le disque pour les metadata (1% chez moi)
      - système encore utilisable lors d'un méchant sync/copie en cours
      (juste la détection des modifications sur les fichiers qui marche pu jusqu'à la fin de l'opération ou du sync manuel)

      Bon après le xfs a ses problèmes :
      - noyau par défaut mandriva 2.6.17 complètement moisi
      (je tourne en 2.6.20tmb qui marche niquel et n'a plus de problème de corruptions de donnée comme le 2.6.17)
      - xfs_repair peux segfaulter lors d'un fsck du filesystème (a cause d'un block physique défectueux dans chaque cas chez moi)
      Là c'est la merde, disons les choses clairement !
      Un second lancement de xfs_repair enverra tout ou presque dans lost+found...

      Mais j'ai jamais eu vraiment intérêt a lancer un fsck dessus et mes expériences me montre qu'il faut éviter (en fait c'est fait tout seul au remount par le noyau).

      - Démontage forcé du filesystème si vous le remplissez complètement et qu'il a pas été démonté correctement (démontage/remontage et retrait de quelques fichier et c'est réglé)
      - non support de selinux (il faut a la création du filesystème mettre des inodes de 512 si je me souviens bien).

      Bref, le XFS c'est bien, mais son gros défaut est la qualité du matériel, des blocs défectueux et il fera pas de miracle...
      A noter qu'il y a DEUX block de métadata (organisation des inodes, etc), et que le premier corrompu, le second sera utilisé (ça m'est arrivé une fois sur le premier, j'ai rien perdu).

      - IMPOSSIBLE DE RÉCUPÉRER DES DONNÉES !!!
      en fait la seule solution est de faire ceci :
      - on viens de delete le travail d'une vie
      - pas encore de sync du disque appuyez sur reset
      - booter un live cd et lancer :
      xfs_repair -L /dev/hdXY
      - monter le système de fichier (et là prier que le replay log aient pas encore été appliqué et que les inodes soient toujours connectés)

      J'ai sauvé des fichiers comme ça une fois... (depuis je crois aux miracles ;)

      • [^] # Re: Mes benchs à moi

        Posté par  . Évalué à 2.

        > Le ext3 a été dégagé pour d'autre raison :
        > - perte de donnée

        C'est marrant. Un mec fait un test avec ext3 et a des pertes de données. De nombreuse (million?) personnes utilisent ext3 et n'ont pas de pertes de données (ou c'est très rare).

        > - corruption totale d'une partiton de 67Go !

        cf ci-dessus. Si ext3 était naze, tu crois que Red Hat l'utiliserait ? Red Hat l'utilise pour des données critiques sur des gros serveurs et doivent tourner 24/24 7/7 365/365.

        > (alors que je faisais des sync régulier pour l'éviter et aucune freeze lors de ces sync)

        Si t'as un système qui freeze, alors tu as d'autres problèmes. Problème hardware ou problèmes qui écrit n'importe où en mémoire. Dans ce cas tous les FS peuvent se planter (avec perte de données et tout).
        Il y a eu le cas avec ext3. Le module ntfs (même en ro) écrivant n'importe ou en mémoire et foutait la merde dans les données d'ext3. Il y a eu des cas de FS irrécupérable. NB : ntfs a été corrigé.
        Il y a eu aussi ce problème avec le module NVidea.

        > - pas de fsck de 3h, tu remonte et paf c'est finis

        Avec ext3, ce n'est qu'une question de configuration. Fais "man tune2fs" et "man fstab".
        Sans fsck complet, il est impossible pour un FS de détecter un problème hardware (sauf via le retour des fonctions read() et write()). Donc un fsck régulier, même s'il n'est pas exigé par le FS, ne peut pas faire de mal. Loins de là.

        > je tourne en 2.6.20tmb

        Ben si tu tournes avec des noyaux en développement, plus du "bleeding edge", il ne faut pas s'étonner qu'ext3 (ou n'importe quel fs) plante.

        • [^] # Re: Mes benchs à moi

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

          > C'est marrant. Un mec fait un test avec ext3 et a des pertes de données.
          > De nombreuse (million?) personnes utilisent ext3 et n'ont pas de pertes
          > de données (ou c'est très rare).
          Tant mieux pour eux, mais pour moi avoir de la corruption des données non utilisée sur le système de fichier en case de freeze n'est pas acceptable.
          (note que j'avais un cas particulier de matos défaillant et que pas grand monde dois avoir ce genre de problème récurant)

          De plus le plus gros problème est que mon système passait plus de temps en fsck que allumé a cause de ça (et bon skiper le fsck donnais des résultats encore pire...)

          > cf ci-dessus. Si ext3 était naze, tu crois que Red Hat l'utiliserait ?
          > Red Hat l'utilise pour des données critiques sur des gros serveurs et
          > doivent tourner 24/24 7/7 365/365.
          Tu crois que redhat tourne avec du matos pour particulier comme moi ?
          Les contraintes sur un raid5 matériel sont pas les mêmes que les miennes
          (système de fichier chiffrées qui ont rien a voir au niveau consommation cpu)

          Red hat n'a pas aussi des télé-chargements de torrents en parallèle massif a écrire sur des disques durs en limitant la consommation cpu du SF parce que cryptoloop le charge déjà a mort...
          Tout en gardant le système opérationnel pour soutenir 400ko/s de flux descendant !

          > Ben si tu tournes avec des noyaux en développement, plus du "bleeding edge",
          > il ne faut pas s'étonner qu'ext3 (ou n'importe quel fs) plante.
          Avant de parler, va relire le changelog du 2.6.20 (ui là je suis méchant de faire une réponse pareille), tu verras que des cas de plantages du XFS ont été corrigés dedans (défectueux depuis 2.6.17 au moins), j'ai donc une très bonne raison d'utiliser ça.

  • # Reiserfs (<=3.6)

    Posté par  . Évalué à 7.

    C'est ce que j'utilise principalement depuis 3-4 ans et plus, et niveau corruption de données, ben je vais en étonner un, mais ça n'est jamais arrivé, même avec une machine - qui a d'ailleurs rendu l'âme y a un an - qui subissait beaucoup de coupure de jus.
    Pour la redimension pur, j'en sais rien, mais avec LVM2 ça ne m'a pas posé de problème.

    Note qu'avec Reiserfs, c'est assez facile de récupèrer ses fichiers effacés contrairement à Ext3 dont aucuns utilitaires libres n'existe.

    Parcontre, sur la longeur et durée, je n'ai pas senti Reiser4 très performant, c'est donc pour cela que je suis resté en 3.6. et que j'en suis très content.

    voilà

    • [^] # Re: Reiserfs (<=3.6)

      Posté par  . Évalué à 5.

      Je suis étonné de découvrir qu'il y aurait des problèmes avec Reiserfs. J'utilise Reiserfs depuis des années, 5,6 ans, j'ai oublié. En tous cas, je suis passé de ext2 à Reiserfs, sans avoir jamais rencontré la moindre corruption, plantage. Mieux, il m'est arrivé de couper l'alimentation de la machine brutalement. Ca redemarre sans aucun problème, en demandant quelques secondes en plus, évidemment, avec l'histoire de la journalisation. Aucun souci donc. Je l'utilise sur des disques ide et sata.
      J'avais essayé ext3 à ses débuts et il m'était apparu lent par rapport à Reiserfs.

  • # Benchmark

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

    C'est un blog anglais de très bonne qualité:

    http://linux.inet.hr/first_benchmarks_of_the_ext4_file_syste(...)

    http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

    • [^] # Re: Benchmark

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

      oui mais moi, je parle anglais avec une mauvaise qualité ... c'est grave ? ou je peux quand meme aller le voir ce blog ? :)

  • # LVM

    Posté par  . Évalué à 1.

    Le problème de ext3 avec LVM, c'est qu'il n'est pas possible d'agrandir un volume logique sans démonter le FS. Et là, un FS de type XFS est intéressant. Je ne parle pas d'un desktop, mais d'un serveur où on ne tient pas à arrêter la prod.

    • [^] # Re: LVM

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

      Dans le meme style, XFS supporte le freeze, et c'est bien pratique.
      cf http://linuxfr.org/comments/729837.html#729837

    • [^] # Re: LVM

      Posté par  . Évalué à 1.

      Le problème de ext3 avec LVM, c'est qu'il n'est pas possible d'agrandir un volume logique sans démonter le FS

      Je n'ai pas de lien, mais je suis à peu près sur que redhat (en premier, d'autres ont suivi) a intégrer un patch permettant cela il y a 1 ans (ou plus ?), j'imagine qu'il est partout maintenant.

      • [^] # Re: LVM

        Posté par  . Évalué à 5.

        RESIZE2FS(8)

        NAME
        resize2fs - ext2/ext3 file system resizer

        SYNOPSIS
        resize2fs [ -d debug-flags ] [ -S RAID-stride ] [ -f ] [ -F ] [ -p ] device [ size ]

        DESCRIPTION
        The resize2fs program will resize ext2 or ext3 file systems. It can be used to
        enlarge or shrink an unmounted file system located on device. If the filesys-
        tem is mounted, it can be used to expand the size of the mounted filesystem,
        assuming the kernel supports on-line resizing. (As of this writing, the Linux
        2.6 kernel supports on-line resize for filesystems mounted using ext3 only.).

        • [^] # Re: LVM

          Posté par  . Évalué à 2.

          Y'a pas une histoire par contre que seule la fin de la partition peut être déplacée, et pas le début ?

          • [^] # Re: LVM

            Posté par  . Évalué à 2.

            sisi, et puis en général on ne peut pas "bouger" des partitions sur un disque (du moins avec les outils que j'ai utilisé), je cherche mal ? c'est impossible car les petits octets risquent d'attraper froid ? Sinon j'avais pensé y aller avec dd mais je me renseigne avant :)
            (sinon je trouve triste le peu de support de redimension alors que le système de fichiers est monté)

Suivre le flux des commentaires

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