Sortie de la version 4 de ReiserFS

Posté par  . Modéré par rootix.
0
24
août
2004
Noyau
La version 4 du système de fichiers Reiserfs vient de sortir.

Reiserfs est un système de fichiers journalisé, c'est à dire qu'il apporte un gain de sécurité en terme d'intégrité des données par rapport à un système de fichiers classique. Cette version a été écrite sans utiliser le code de la version précédente, qui sera toujours maintenu pour corriger les bugs le cas échéant. Les développeurs affirment avoir conçu cette nouvelle mouture en portant une attention particulière à la qualité du code.

Reiserfs supporte les transactions atomiques : une modification sur le disque est effectuée ou non, mais elle n'est jamais effectuée "à moitié". Cela permet de s'assurer en permanence de l'intégrité du système de fichiers. Cette atomicité ne s'effectue pas au dépend des performances grâce à un algorithme assez sophistiqué.
Au menu également les "dancing trees", qui rendent obsolètes les "B-trees" utilisés auparavant. Cette technologie permet de gérer des systèmes de fichiers d'une taille importante. Reiserfs 4 intègre maintenant un système de plugins afin de faciliter le développement de fonctionnalités supplémentaires. Toutes ces fonctionnalités permettent d'envisager de nouvelles applications, ainsi sa très grande facilité de gestion de nombreux petits fichiers lui permettrait de remplacer avantageusement une base de données dans certains cas.

Au final Reiserfs met la barre assez haut et n'a pas à rougir face à ses principaux rivaux (ext3 notamment).

NdM : merci à Dario Spagnolo et à Mark Havel pour avoir également proposé des dépêches sur le sujet. NdM : Reiseir4 est distribué sous forme d'un patch pour les noyaux 2.6 récents. Ce patch a été aussi récemment intégré au patchset -ck de Con Kolivas et à la branche expérimentale -mm d'Andrew Morton. Son intégration dans le 2.6 stable n'est pour l'instant pas planifiée. Enfin, il n'est pas disponible pour les noyaux 2.4.

Aller plus loin

  • # déjà qlqs commentaires là

    Posté par  . Évalué à 6.

    dans le journal de Brice Arnould :
    http://linuxfr.org/~98111/15041.html(...)
    • [^] # Re: déjà qlqs commentaires là ==> Performances

      Posté par  . Évalué à 8.

      J'en profite pour rappeler ce qui y a été dit au sujet des performances : les benchs sont vieux, sur de vieux noyaux et fait par namesys
      donc si quelqu'un connait de bons benchs récents, complets et indépendants, ça serait mieux
    • [^] # Re: déjà qlqs commentaires là

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

      Attention, l'article n'est pas très rigoureux sur les noms. Alors, soyons précis :
      - Hans Reiser est le nom de l'auteur, un homme aussi sympathique et discret que compétent dans ce domaine. Nous l'avons rencontré lors des premières RMLL en 2000 (*).
      - reiserfs nom du système de fichier créé par Hans Reiser. Il y a eu trois versions majeures.
      - reiser4 C'est le nouveau système de fichier. C'est aussi un changement de nom puisque "fs" a disparu du nom et est remplacé par un chiffre.

      (*) Hans Reiser et David Axmark (MySQL) ne s'étaient pas quitté pendant les RMLL. Ils avaient pu comparer la problématique des transactions avec celle de la journalisation et aborder divers autres points à la frontière de leurs spécialités. David Axmark a ensuite implémenté les transactions et reiser4 a bien des points communs avec une base de données....
  • # Kadreg est mailleur avec Photoshop

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

    Après avoir s'être fait sponsorisé par SuSE pour le développement de Reiser3 et par Lindows.com pour le debuggage de Reiser4, j'espère que Reiser va réussir à trouver un autre sponsor pour payer des cours de Gimp au graphiste.
    Quand je vois des horreurs comme http://namesys.com/r4pics/sequencebytes.jpg(...) j'hésite à utiliser ReiserFS, craignant de retrouver mes images toutes salies avec du texte mélangé.
  • # Gestion des ACLs

    Posté par  . Évalué à 2.

    J'ai pas le temps de parcourir les docs donc si quelqu'un connait la réponse à :
    Est ce que ReiserFS support les ACLs ?
    • [^] # Re: Gestion des ACLs

      Posté par  . Évalué à 1.

      En tout cas, il n'est pas fait mention de ce système sur le guide des ACL de LinuxFrench :
      http://www.linuxfrench.net/gnu_linux/comment_fonctionnent_les_acl_p(...)
    • [^] # Re: Gestion des ACLs

      Posté par  . Évalué à 3.

      Après un (rapide) tour chez notre ami google, j'ai trouvé ça :
      http://thebsh.namesys.com/snapshots/2004.02.25/READ.ME(...)

      Il semblerait donc bien que le support ACL soit là.
    • [^] # Re: Gestion des ACLs

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

      Reiserfs 3 gère très bien les ACL avec un kernel 2.6.
      Pour ce qui est de reiserfs 4, je ne sais pas.
    • [^] # Re: Gestion des ACLs

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

      Sur http://namesys.com/v4/v4.html(...) il est dit que l'intégration des ACLs a été pensée, et que donc l'architecture du système de plugins le permet (si j'ai bien capté) mais que c'est pas encore fait.
      Une bonne ocaz' de découvrir l'API donc -_^. De toutes manières, elles seront probablement implémentées de 60 manières différentes avant même que Reiserfs4 ne soit disponible en production.
      • [^] # Re: Gestion des ACLs

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

        Pour ceux, qui, comme moi, les ACL ça dit vaguement quelquechose(voir a qui ça ne dit rien du tout), mais ne se rappellent plus ce que c'est, j'ai trouvé une très bonne explication ici:

        http://okki666.free.fr/docmaster/articles/linux100.htm(...)
        • [^] # Re: Gestion des ACLs

          Posté par  . Évalué à 5.

        • [^] # Re: Gestion des ACLs

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

          Si tu ne sait pas ce que sont les ACLs, c'est que t'en a pas besoin, non ?

          "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

          • [^] # Re: Gestion des ACLs

            Posté par  . Évalué à 4.

            Et ?
            Et bien il dit qu'il a plus de genou.
            Il a peut-etre juste envie de savoir ce que c'est. Faut etre un peu ouvert dans la vie. La curiosite n'est pas un vilain defaut :)
            • [^] # Re: Gestion des ACLs

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

              Je parlais dans le cas précis des ACLs, c'est le genre de truc qu'il vaut mieux ne pas utiliser si tu ne sais pas ce que c'est.
              Si c'est juste pour le fun, bien sûr, il faut le faire puisque c'est inutile ;) Par contre, si c'est pour utiliser en production, vaut bien connaître le sujet.
              C'est un peu comme se faire un cluster de User-Mode Linux ou installer Hurd...

              "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

        • [^] # Re: Gestion des ACLs

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

          Je dirais que les ACLs suppriment les limitations du modèle rwx sur le owner, groupe et all (même avec les petits plus que sont les setuid et setgid), puisqu'on peut faire une liste illimitée de droits unitaires sur les fichiers et répertoires.

          En d'autre termes, c'est absolument nécessaire, et à vrai dire ça ne devrait pas être une option du tout, mais bel et bien une fonctionnalité de base de tout FS sous Linux. De même, toutes les applis et interfaces graphiques devraient pourvoir gérer les ACLs, ce qui est loin d'être le cas actuellement.

          Un des problèmes, c'est qu'entre XFS et Ext2/Ext3, ça n'est pas la même chose (commandes, etc.). Autre problème, le mapping Samba des ACLs Linux est simple voire simpliste mais ne correspond pas (est une sous-ensemble) des ACLs du monde Windows (NT-family). Encore un autre problème, les ACLs ne sont pas sauvegardés par les outils standards (GNU tar, etc.).

          Je suis partisan du "ACL-everywhere" normalisé dans le monde Linux, et ne suis pas le seul.
          • [^] # Re: Gestion des ACLs

            Posté par  . Évalué à 0.

            Les ACLs sont bien plus complexes à gérer (admin) et à comprendre (utilisateur) que les droits *nix classique.

            Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).
            • [^] # Re: Gestion des ACLs

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

              > Les ACLs sont bien plus complexes à gérer (admin) et à comprendre (utilisateur) que les droits *nix classique.

              Les ACLs sont - au contraire - bien plus simples à gérer et comprendre car elles sont intuitives, ce qui n'est pas le cas du modèle rwx doublé des setuid+setgid (moins les aspects habitude de l'utilisateur/admin).

              > Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).

              Elles sont également nécessaires dans un environnement bureautique Samba (authentification sur domaine + partages de répertoires et d'imprimantes autant sur des serveurs que des stations), autrement dit dans le cas d'un parc bureautique hétérogène Linux+Windows, donc à peu près partout où Linux essaie de s'insérer dans une entreprise ou une administration (puisque Windows est présent partout).

              Idem pour les environnements Novell a priori je pense, à vérifier. Des utilisateurs de réseaux Novell peuvent-ils nous confirmer qu'ils utilisent bien les ACLs ?

              Mac OS X ayant également Samba inclus un peu partout dans le système, il doit certainement avoir des ACLs, non ? Quelqu'un pour confirmer ?
              • [^] # Re: Gestion des ACLs

                Posté par  . Évalué à 2.

                >Les ACLs sont - au contraire - bien plus simples à gérer et comprendre car elles
                >sont intuitives, ce qui n'est pas le cas du modèle rwx doublé des setuid+setgid
                >(moins les aspects habitude de l'utilisateur/admin).

                http://www.suse.de/~agruen/acl/linux-acls/online/(...) pour vous faire une idée et comparer avec les droits *nix classique :)



                >> Elles ne sont necessaires à mon avis que dans le cas d'un serveur (notament serveur de fichier).
                >Elles sont également nécessaires dans un environnement bureautique Samba

                Je crois que tu répètes ce que je viens de dire....
                A noter qu'il faut pas que ce soit trop homogène non plus MacOS9 n'aime pas les ACL...
            • [^] # Re: Gestion des ACLs

              Posté par  . Évalué à 2.

              Ou bien dans le cas d'un poste partagé par plusieurs personnes.
          • [^] # Re: Gestion des ACLs

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

            > Autre problème, le mapping Samba des ACLs Linux est simple voire
            > simpliste mais ne correspond pas (est une sous-ensemble) des ACLs
            > du monde Windows (NT-family)

            C'est pas trop le mapping samba qui pose problème, c'est plutôt le modéle des ACL posix non ? Les ACL Windows à partir de 2000 sont bien plus complettes et compliqué que les ACL posix.

            Ce qui me géne le plus c'est le manque de délégation pour la gestion des droits des fichiers (seul root et le owner ont ce droit).

            > Je suis partisan du "ACL-everywhere" normalisé dans le monde Linux,
            > et ne suis pas le seul.

            Ensemble ça fait déjà deux ;)
            • [^] # Re: Gestion des ACLs

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

              > Les ACL Windows à partir de 2000 sont bien plus complettes et compliqué que les ACL posix.

              s/bien plus/trop/ ?

              Il y a vraiment trop de bruit dans les ACLs NT àmha. Mais bon, GNU/Linux sans ACLs fait quand même playschool à côté... ;-)
            • [^] # Re: Gestion des ACLs

              Posté par  . Évalué à 4.

              La gestion des ACLs n'est qu'un sous-ensemble de la gestion de la sécurité.
              Pour ce qui est de la délégation, SELinux devrait apporter un équivalent bien plus puissant.

              Le hic pour l'instant reste la complexité de sa mise en place, mais debian, gentoo, redhat, suse sont en train d'y reflechir pour apporter ces outils à l'utilisateur de tout les jours. Ca avance, et vite !

              Ce que j'attend avec impatience pour m'y lancer à fond, c'est la gestion SELinux d'Xfree.

              Actuellement en cours de développement dans le cvs d'XOrg (branche XACE), sa sortie devrait démocratiser son utilisation.
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Gestion des ACLs

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

      La suse 9.1 utiliser reiserfs3 + acl par defaut.
      Pour le 4 je sais pas.
  • # Conseils ?

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

    Voilà, depuis que je suis sous Linux, j'utilise de l'ext3 partout.

    Cependant, j'entend parler de ReiserFS, XFS, etc...

    J'aimerais savoir lequels employer pour un maximum de performances pour :

    - la partition /
    - la partition /home/
    - la partition qui contient mes rushes videos DV (entre 150 et 400Mo le fichier)

    Qu'ai-je à gagner à utiliser un système plutôt qu'un autre ?

    Je remercie d'avance celui qui prendra la peine d'un jour faire une petite comparaison assez simple et les domaines d'utilisation spécialisés de chaque FS. Je crois que je ne serai pas le seul à en profiter ;-)

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Conseils ?

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

      Je ne peux pas parler de performances, je n'ai pas fait de tests, mais pour la partition root (au moins), l'ext3 a l'immense avantage d'être compatible avec ext2, ce qui est une garantie que n'importe quel kernel Linux sera capable de monter la partition... utile en cas de crash, si tu veux utiliser un CD/clé USB/disquette pour booter.

      Cependant, cet avantage perd de son importance au fil du temps. Moins la mémoire sera limitée et plus les noyaux supporteront de systèmes de fichier de base.
      • [^] # Re: Conseils ?

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

        Tous les noyaux récent sur distrib "récentes" sous forme de live cd sont capablent de monter du reiserfs (et du xfs pour les noyau 2.6).

        Je suis étonné que l'on compare reiserfs a l'ext3 qui est très lent.
        Reiserfs est en théorie très rapide sur les petits fichier.

        Le fs super rapide est l'ext2 mais n'est presque plus d'actualité pour les partition autres que le /boot. Attention au crash !

        xfs est souvent bien classé mais j'ai eu pas mal de soucis avec lors de plantage -> fichiers corrompu. (le genre de truc que l'on évite avec les transaction atomique par ex).

        Là je suis plutot content de ma reiserfs 3.6
        • [^] # Re: Conseils ?

          Posté par  . Évalué à 3.


          Le fs super rapide est l'ext2

          D'aprés leurs benchs reiserfs4 semble être plus rapide que l'ext2 maintenant.
          Par contre, les résultats CPU_TIME indiquent qu'il sollicite plus le processeur.
          Quelqu'un sait il à quoi correspond la colonne DF?
          • [^] # Re: Conseils ?

            Posté par  . Évalué à 7.

            Quelqu'un sait-il à quoi correspond la colonne DF?

            Je suppose qu'il s'agit du nombre de blocs occupés (ou libres), résultat de la commande usuelle "df", pour évaluer l'effacité de stockage du FS.
      • [^] # Re: Conseils ?

        Posté par  . Évalué à 1.

        Oui, enfin... TOUS les noyaux, euh.. non.
        Y'a plein de soucis dans des cas, genre si ton fichier journal est en vrac, si t'as certains type de corruption, etc, qui font que tu n'y arrivera pas forcément. Il vaut vraiment mieux avoir un kernel qui connaît bien ton FS, et les fsck qui vont avec.

        Et le souci, c'est que tu monte toujours un vieux noyau quand ton FS est corrompu.. donc en plein dedans :)

        Mais c'est vrai que la compatibilité EXT2/3, sur touts les autres aspects, est pratique.
    • [^] # Re: Conseils ?

      Posté par  . Évalué à 10.

      Perso j'ai utilisé principalement ext3 et reiserfs3 jusqu'ici. Je me souviens avoir senti la différence de perfs entre les deux en faisant des grosses compiles (gros avantage pour reseirfs3, parceque c'est justement sur les nombreux accès à des petits fichiers qu'il excelle). Mais j'ai abandonné reiserfs3 depuis parceque ça m'est arrivé une fois où deux d'avoir des corruptions ou pertes de fichiers suite à des shutdowns violents, alors qu'avec ext3 jamais. Bon, c'est mon expérience, ça vaut ce que ça vaut hein...

      Sinon, de ce que j'ai lu, c'est probablement XFS qui serait le plus adapté à ta partoche de vidéos. Il est apparement le plus performant pour les accès bien linéaires à des gros fichiers (streaming ou capture vidéo, etc.).

      Quant à Reiser4, perso je vais tester pour ma prochaine installe de distrib¹. Sur le papier au moins, la robustesse à l'air d'être au rendez-vous cette fois, mais surtout j'ai bien envie de jouer avec les plugins, les fichiers aggregés, tout ça quoi. Y'a vraiment de l'inovation sur les features et pas juste une course à la vitesse, et ça ça mérite d'être essayé.

      ¹ D'ailleurs si qlqun connais un LiveCD supportant Reiser4 pour que je puisse amorcer un install gentoo, ça m'intérresse. Enfin sinon j'en ferais un, c'est pas bien grave.
      • [^] # Re: Conseils ?

        Posté par  . Évalué à 5.

        > Je me souviens avoir senti la différence de perfs entre les deux en faisant des grosses compiles (gros avantage pour reseirfs3, parceque c'est justement sur les nombreux accès à des petits fichiers qu'il excelle).

        Pour les compilations ?
        Tu es sûre ?
        Quand je compile, tout est en cache et le cpu est utilisé à 100 %.

        Je ne suis pas un dingue de reiserfs, mais j'avoue qu'il me semble globalement plus rapide qu'ext3. Mais pas pour les compilations.
        • [^] # Re: Conseils ?

          Posté par  . Évalué à 3.

          > Quand je compile, tout est en cache

          Comme tu le dis plus bas, ça n'est vrai que si la mémoire suit. À l'époque où j'utilisait du reiserfs, j'étais sur une petite config très juste à ce niveau, et ceci explique peut être celà. Bon maintenant, c'est vieux, donc je vais pas jurer cracher non plus, mais quand même, mon souvenir est vraiment celui d'une bonne surprise à ce niveau les premières fois que j'avais testé reiserfs.
        • [^] # Re: Conseils ?

          Posté par  . Évalué à 3.

          Que ton cpu soit utilisé à 100% lors d'une compilation ne m'étonne guère. Le contraire serait même inquiètant..

          Reiser et ext3 n'ont pas d'optimisations spéciales quand aux compilations. Ce qui n'est pas le cas de reiser4 puisque, dès sa sortie, il supporte déja le plugin "fibration" qui consister à "mettre" cote à cote les fichiers ayant une extention identique, ce qui tendrait à accélérer les lectures/ecritures des .o et .c lors des compilations.
      • [^] # Re: Conseils ?

        Posté par  . Évalué à 4.

        "D'ailleurs si qlqun connais un LiveCD supportant Reiser4 pour que je puisse amorcer un install gentoo, ça m'intérresse. Enfin sinon j'en ferais un, c'est pas bien grave."

        La derniere YOPER en mode rescue semble répondre à ton besoin.

        http://www.yoper.com/(...)

        "Known to be a commercial strength Desktop Solution at 0 cost, this release provides the power user with many new features, encompassing REISER4 support for the root filesystem, new non-destructive NTFS resizing, graphical partitioning, option to use GRUB or LILO bootloaders, a new clustered control panel, KDE 3.3.0 Final, Linux Kernel 2.6.8.1, default Firewall and the OpenOffice.org Office Suite, all provided on 1 CD. The default "look and feel" has been enhanced and many bugfixes have been applied, including PCMCIA support during install and support for PPPoE."
    • [^] # Re: Conseils ?

      Posté par  . Évalué à 8.

      On ne peut pas vraiment comparer ReiserFS (ou XFS,etc...) à ext3, car ils ne boxent pas dans la même catégorie....ext3 ne fait que rajouter la journalisation à l'antidéluvien système de fichier ext2, c'est donc toujours un système de fichier avec une décennie de retard maintenant, alors que les autres systèmes de fichiers cités sont tous basés sur des théories du système de fichier beaucoup plus puissantes et évoluées....
      Pour y voir plus claire : http://jfenal.free.fr/Traduc/LG55D/lg55d-fr/lg55d-fr-4.html(...)
      • [^] # Re: Conseils ?

        Posté par  . Évalué à 7.

        ext3 ne fait que rajouter la journalisation à l'antidéluvien système de fichier ext2

        ext2 n'est pas le plus récent des systèmes de fichiers, mais il reste assez performant, même sur grosses partitions (qui n'existaient pas quand le FS a été conçu). En usage courant, chez moi ext3 est tout à fait satisfaisant (par ex, un "dd if=/dev/zero of=/big/toto" sur 1 Go se déroule à une vitesse proche de la vitesse d'écriture brute du disque), en tous cas je n'ai jamais perdu de fichier (il est vrai que je n'ai que très rarement eu de coupure brutale ou plantage), et c'est le plus important à mes yeux.
        Je ne suis pas sûr qu'un FS conçu plus récemment soit beaucoup plus performant, surtout pour l'usage que nous avons généralement de nos machines (en tant que particulier).

        NB: c'est antédiluvien ("anté" = avant, "diluvien" indique le déluge).
      • [^] # Re: Conseils ?

        Posté par  . Évalué à 10.

        > Pour y voir plus claire : http://jfenal.free.fr/Traduc/LG55D/lg55d-fr/lg55d-fr-4.html(...)

        On y voit rien !
        Ext3FS :
        1) Taille maximale du système de fichiers : 4 To
        2) Taille de blocs : De 1 à 4 Ko
        3) Taille maximale de fichier : 2 Go

        1) => faux. je n'ai pas d'url sous la main mais c'est faux au moins pour Linux 2.6
        2) => vrai ! bravo !
        3) => faux.
        Voilà un de mes répertoires (j'enregistre les JO :-) :
        $ ll -h
        total 14G
        -rw-r--r-- 1 me me 1,5G aoû 24 21:00 JO_2004-08-24-19:52.avi
        -rw-r--r-- 1 me me 2,5G aoû 24 23:00 JO_2004-08-24-21:00.avi
        -rw-r--r-- 1 me me 1,8G aoû 25 00:00 JO_2004-08-24-23:00.avi
        -rw-r--r-- 1 me me 4,6G aoû 25 02:00 JO_2004-08-25-00:00.avi
        -rw-r--r-- 1 me me 3,8G aoû 25 03:29 JO_2004-08-25-02:00.avi

        C'est qu'un exemple...

        Sinon ext3 supporte aussi htree. Il faut faire :
        tune2fs -O dir_index /dev/...
        e2fsck -f -D /dev/...

        Je veux bien admettre qu'ext3 n'est pas la F1 des FS, mais ce n'est pas une 2CV.
        De plus il a presque toutes les fonctionnalités et en rock solide. Il ne manque que le resize à chaud et c'est actuellement en phase de debug (dans FC2 et ça marche :-)).
        • [^] # Re: Conseils ?

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

          "De plus il a presque toutes les fonctionnalités et en rock solide. Il ne manque que le resize à chaud et c'est actuellement en phase de debug (dans FC2 et ça marche :-))."

          Mwai, il n'empeche que ext3 n'a rien d'un fs moderne, il a pour base ext2 et c'est ca qui craint le plus. Il y'avait eu un tres bon article dans Linux Mag y'a deux ans(me semble) sur le sujet qui expliquait les caracteristiques de tous les FS.

          Je trouve juste dommage que redhat/mdk restent bloqués sur ce fs juste pour une histoire de compatibilité ext2. Bon, je sais, comme tu l'as dit, y'a pas que ca, redhat aime bien ext3 pour des raison techniques mais qui ne concerne que la journalisation.
          • [^] # Re: Conseils ?

            Posté par  . Évalué à 9.

            "Mwai, il n'empeche que ext3 n'a rien d'un fs moderne, il a pour base ext2 et c'est ca qui craint le plus.
            Je ne vois pas pourquoi ext2 crait. Au contraire c'est sans doute le système de fichier le plus robuste et le plus éprouvé. Regarde les changelogs et tu comprendras. Et je trouve bien qu'on se base sur un système de fichiers robuste afin d'hériter de la caractéristique primordiale. C'est vrai qu'Ext3 a eu et a encore quelques désavantages par rapport aux autres dû à l'heritage d'ext2 (acl, taille maximum...) mais peu à peu il les comble. Et je trouve ça plutôt sain comme mode de développement.
            Sur le papier reiserfs 4 est peut-être le meilleur. Maintenant faut voir en pratique parce que on a eu le même discours avec la version 3 et pour être reparti de zéro faut croire qu'il était pas si bien que ça.
            • [^] # Re: Conseils ?

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

              "Je ne vois pas pourquoi ext2 crait. Au contraire c'est sans doute le système de fichier le plus robuste et le plus éprouvé."

              Oui, mais un fs vieux avec de vieux concepts dedans, pour resumer l'article de linux mag. En clair, XFS, reiserfs et autres utilisent des algos bien plus perfectionnés que ce que l'on trouve dans ext2.

              "et pour être reparti de zéro faut croire qu'il était pas si bien que ça. "

              Rien à voir, c'est pas parce que ils ont innovés que l'ancienne version etait mauvaise.
              • [^] # Re: Conseils ?

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

                "Je ne vois pas pourquoi ext2 crait. Au contraire c'est sans doute le système de fichier le plus robuste et le plus éprouvé."
                Oui, mais un fs vieux avec de vieux concepts dedans, pour resumer l'article de linux mag. En clair, XFS, reiserfs et autres utilisent des algos bien plus perfectionnés que ce que l'on trouve dans ext2.


                Et pour toi cela suffit à dire qu'un système de fichier craint ???
                Pour moi, un SGF qui craint est un système de fichier peu fiable, peu performant... Dis tu que ext3 est ainsi ?
                Pour ma part j'ai eu quelques coupure violentes et je n'ai jamais eu aucun problème. Je touche de la peau de singe (oups c'est ma tête).

                Tu sembles dire que Redhat et Mandrake restent sur ext3 et que cela est dommage. Néanmoins, je pense que leur équipe de développement et des gens comme Alan Cox sont largement compétents pour prendre telle descision :-)


                "et pour être reparti de zéro faut croire qu'il était pas si bien que ça. "
                Rien à voir, c'est pas parce que ils ont innovés que l'ancienne version etait mauvaise.

                Alors là je suis totalement d'accord avec toi. Ils ont eu d'autres idées et ont essayer d'évoluer et progresse voilà tout.

                Christophe
                • [^] # Re: Conseils ?

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

                  "Et pour toi cela suffit à dire qu'un système de fichier craint ???"

                  Ext3 est montrer comme un fs moderne et ce n'est pas le cas, comme le disait l'article de LinuxMag, c'est un fs de transition pour ext2. Mais sur une machine neuve, mieux vaut passer à quelques chose de mieux pensé. J'ai pas dit ext3 craint, j'ai dit ext2 craint. Je suis sur que la partie journalisation de ext3 est de bonne qualité mais le fs dessous(ext2) lui est tres basique. C'est un peu comme si Microsoft avait sortie la Fat 32++ (Fat 32 + journalisation + ACL) au lieu de NTFS ;)

                  "Tu sembles dire que Redhat et Mandrake restent sur ext3 et que cela est dommage. Néanmoins, je pense que leur équipe de développement et des gens comme Alan Cox sont largement compétents pour prendre telle descision :-)"

                  Deja, tu enleves Mandrake vu que leur politique est de faire comme RedHat :) Il y'a plein de truc suxorisant dans la Mandrake qui sont la paske c'est comme ca chez RedHat: le rc.sysinit par exemple. Je sais je me repete, mais bon, quand on compare un init Debian/Suse(similaire) à un init RedHat/Mandrake, y'a d'un coté la modularité et de l'autre la rigidité. Et franchement, je crois que leurs equipes de devel(de rh et mdk) sont capables d'ecrire un truc un peu mieux pensé que ce script qui ressemble au premier programme C d'un edudiant d'IUT premiere année.

                  Donc dire RedHat l'a choisit donc c'est une bonne solution, ca me fait sourire ;)
                  • [^] # Re: Conseils ?

                    Posté par  . Évalué à 5.

                    « C'est un peu comme si Microsoft avait sortie la Fat 32++ (Fat 32 + journalisation + ACL) au lieu de NTFS ;) »

                    Hormis l'effet dévalorisant que tu semble chercher à produire en comparant fat et ext2, j'ai l'impression, sans être un spécialiste, que fat et ntfs sont beaucoups plus éloigné l'un de l'autre que ext2 et ext3/reseirfs/xfs, ...
                    Déjà rien que le fait que ext2, ntfs, reseirfs sont multiutilisateur et pas fat.


                    gnumdk:
                    « [...]Il y'a plein de truc suxorisant dans la Mandrake[...] »

                    On renie son premier amour ? ;-)
                    • [^] # Re: Conseils ?

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

                      "On renie son premier amour ? ;-) "

                      Non, je dis ce que je pense ;)
                      Apres, et ce n'est que mon avis personnel, je me trompe peut etre, je pense que cette volonté de MandrakeSoft de rester proche de RedHat est surement la pour s'assuré une meilleur compatiblité avec les solutions proprios utilisées en entreprise: Oracle, ... et certifié RedHat. En effet, si Mandrake prend le large par rapport a RedHat, il risque d'etre plus difficile de faire fonctionner ce genre de soft sur une Mandrake.

                      Mais sur d'autre points, Mandrake a su se remettre en question: la modularité des packages par exemple qui se rapproche(sans etre aussi modulaire) de ce que l'on a chez Debian.

                      C'est marrant cette facon que les gens ont de croire qu'une critique n'a lieu que pour descendre ce que l'on utilise pas ;).

                      La distrib que j'utilise actuellement a une facon tres bizarre de packager :) On a du kdebase3, du kdelibs3 à la redhat mais on a du koffice-wordprocessor à la Debian. J'ai toujours pas compris la logique du truc mais bon :)
                  • [^] # Re: Conseils ?

                    Posté par  . Évalué à 3.

                    > RedHat: le rc.sysinit par exemple.

                    Juste pour information, le "monolitique" rc.sysinit fait 861 lignes sur FC2...
                    Y en a qui préfère 10 x 86 lignes mais c'est une affaire de gout.

                    Ça n'empêche pas d'avoir plein de fichiers dans /etc/rc.d/init.d/.
                    Sur FC2 avec tous les paquets, il y a 121 fichiers dans /etc/rc.d/init.d/ !

                    Enfin, rien ne t'empêche d'ajouter des tas d'include dans /etc/rc.d/rc.local .

                    > ce script qui ressemble au premier programme C d'un edudiant d'IUT premiere année.

                    Tu devrais plonger ton nez dedans avant d'avancer ça.
                    • [^] # Re: Conseils ?

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

                      "Ça n'empêche pas d'avoir plein de fichiers dans /etc/rc.d/init.d/."

                      Oui, mais ca empeche de virer des choses lors de l'init autrement qu'a grand coup de vim ;)

                      sous Debian,
                      update-rc.d -f bootmisc.sh remove

                      sous RH/Mandrake
                      vim /etc/rc.sysinit à la recherche du truc.

                      "Tu devrais plonger ton nez dedans avant d'avancer ça."

                      Vu qu'il est tres similaire à celui de la Mandrake et que je connais celui de la Mandrake(on va dire juska la 9.2) tres bien. Je pense pas avoir besoin de le faire.

                      Il faut voir que ce script fait tout et n'importe quoi: hdparm, hostname, ...

                      Sous une Suse par exemple, la modularité est tres bonne:

                      gnumdk@linux:/etc/init.d> ls boot.[!d]*
                      boot.clock boot.klog boot.md boot.scsidev
                      boot.crypto boot.ldconfig boot.proc boot.shm
                      boot.evms boot.loadmodules boot.restore_permissions boot.swap
                      boot.idedma boot.local boot.rootfsck boot.sysctl
                      boot.ipconfig boot.localfs boot.sched boot.udev
                      boot.isapnp boot.localnet boot.scpm

                      Et quand j'etais etudiant en IUT, j'ai commencé la programmation en mettant tout dans le meme fichier. Mes profs m'ont vite fait comprendre que ce n'est pas la bonne méthode.
                      • [^] # Re: Conseils ?

                        Posté par  . Évalué à 1.

                        > vim /etc/rc.sysinit à la recherche du truc.

                        Là tu n'y es pas :-)
                        Désolé.
                        La seul optimisation que tu peux trouver à éditer rc.sysinit est en vitesse de boot. Rien d'autre. rc.sysinit ne lance pas de processus résidents etc (sauf cas exceptionnel).

                        De plus, s'il est possible de déplacer une partie de rc.sysinit dans /etc/init.d sans perte de fonctionnalité, ça sera fait. Mais, par exemple, déplacer l'init de usb dans /etc/init.d est une mauvaise idée (comment faire un fsck par exemple). Idem pour raid.

                        Afin, RedHat/Fedora est une distribution qui "just works" (enfin, ils essaient :-)).
                        Donc rc.sysinit doit toujours initialiser tout les périphériques de façon minimum (usb, raid, etc). Sinon ça veut dire que lorsque tu ajoutes une partition (récupérée d'une autre machine), la partition ne sera pas vue s'il n'y a pas le paquet (ou autre) sysinit_usb ou firewire ou...

                        Juste par curiosité, pourquoi tu veux éditer /etc/rc.d/rc.sysinit à part pour avoir un boot très très légèrement plus rapide.
                      • [^] # Re: Conseils ?

                        Posté par  . Évalué à 2.

                        > Et quand j'etais etudiant en IUT, j'ai commencé la programmation en mettant tout dans le meme fichier. Mes profs m'ont vite fait comprendre que ce n'est pas la bonne méthode.

                        Gros ou petit fichier, ce n'est pas le point ici.
                        Red Hat veux que tout soit initialisé au niveau hard.
                        Red Hat ne veux pas qu'une partie seulement ou quelques parties au chois de l'utilisateur soient initialisées.

                        Tu peux critiquer cette politique si tu veux.

                        Si redhat fait :
                        include boot.usb
                        include boot.udev
                        etc

                        et que les fichiers sont toujours inclus (cas c'est la volonté de RedHat), ça ne change rien par rapport à un "gros" fichier.
                        Par contre, pour les services, Red Hat veut laisser plus de souplesse et là il y a plusieurs fichiers.
                        Mais faire plusieurs fichiers au-lieu d'un gros, sans un réelle objectif de modularité, n'a aucun intérêt. C'est le cas pour le rc.sysinit de RedHat :-) et donc c'est fort logiciquement qu'il n'y a qu'un seul fichier.
                        • [^] # Re: Conseils ?

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

                          "De plus, s'il est possible de déplacer une partie de rc.sysinit dans /etc/init.d sans perte de fonctionnalité, ça sera fait. Mais, par exemple, déplacer l'init de usb dans /etc/init.d est une mauvaise idée (comment faire un fsck par exemple). Idem pour raid."

                          Tu n'as pas compris, c'est pas parce que les fichier sont dans init.d que ca se lance comme les autres services. Comme sous Debian, c'est un autre fonctionnement. Et il n'y pas de perte de fonctionnalité.

                          Apres, le fait de pouvoir virer quelques parties permet sur de tres vieille babasse de gagner un temps precieux au boot ;) Surtout pour le pc de saisie de note de la secretaire qui trouve deja mozilla long a se lancer, alors si en plus le boot est long... :)

                          Mais la n'est pas mon argument principal, il s'agit d'abord d'un probleme de clarté. Suse n'offre aucun outils autre que rm pour virer les liens de boot.* dans /etc/init.d/boot.d (sous debian /etc/rcS.d).

                          Debian offre cette possibilité via la commande update-rc.d.

                          "et que les fichiers sont toujours inclus (cas c'est la volonté de RedHat), ça ne change rien par rapport à un "gros" fichier."

                          Si, la clarté. Si je te code un prog avec une fonction de 800 lignes dans un fichier et un autre avec 80 fonctions de 10 lignes dans 30 fichiers, lequel est le plus clair ? :)

                          Et ton argument : " Red Hat ne veux pas qu'une partie seulement ou quelques parties au chois de l'utilisateur soient initialisées." est vraiment moisi! Le mec qui s'interresse au boot de la redhat, c'est qu'il en a besoin et qu'il sait ce qu'il fait ;)
                          • [^] # Re: Conseils ?

                            Posté par  . Évalué à 2.

                            Je ne dis pas que Debian à tord.
                            J'essaie, mais je n'y arrive pas, d'expliquer pourquoi Red Hat fait comme ça.
                            Pour un usage classique (je ne parle pas d'embarqué qui de toute manière a des scripts spécifiques, ou de la secrétaire qui boot son PC i486 à 33Mhz 10 fois par jours).

                            > Si, la clarté

                            Pour un script de 860 lignes dont le niveau maxi d'indentation est de 5 !
                            Fichtre.

                            > un autre avec 80 fonctions de 10 lignes dans 30 fichiers, lequel est le plus clair ? :)

                            C'est vraiment pas évident.
                            Le "Red Hat touch" :
                            fichier init :
                              # init usb
                              (...)
                              # init ide
                              (...)

                            Le "Debian touch" :
                            fichier init :
                              call init_usb
                              call init_ide
                              (...)

                            fichier init_usb :
                              (...)

                            fichier init_ide :
                              (...)


                            Avec le "Red Hat touch", c'est évident. Tout est excécuté dans un ordre, une fois et c'est tout.
                            Avec le "Debian touch", si je regarde le fichier init_usb, je ne sais pas s'il doit être appelé avant ou après init_ide, je ne sais pas s'il peut être appelé plusieurs fois, etc...

                            Si un programme n'est pas modulaire (comme le rc.sysinit de RedHat) il est inutile de faire croire qu'il est (surtout pour 800 lignes).
                            • [^] # Re: Conseils ?

                              Posté par  . Évalué à 3.

                              L'init Debian, c'est l'init System V
                              Un petit aperçu ici:
                              http://www.debian.org/doc/manuals/reference/ch-system.fr.html#s-ini(...)

                              « Avec le "Debian touch", si je regarde le fichier init_usb, je ne sais pas s'il doit être appelé avant ou après init_ide, je ne sais pas s'il peut être appelé plusieurs fois, etc... »

                              ex:
                              /etc/rcS.d/S26lvm -> ../init.d/lvm
                              /etc/rcS.d/S35mountall.sh -> ../init.d/mountall.sh

                              D'aprés le nom des liens symboliques : S pour Start. Le script lvm démarre en 26ième position alors que mountall.sh démarre en 35 ième position.
                              • [^] # Re: Conseils ?

                                Posté par  . Évalué à 2.

                                > D'aprés le nom des liens symboliques

                                J'image bien que ce n'est pas fait au hazard...
                                Mais la compréhension est moins "fulgurante" qu'avec un "bête" rc.sysinit.
                                Ceci dit, je m'en fous :-)
                                rc.sysinit (tel qu'il est fait par Red Hat) ou /etc/rcS.d/ ne change rien ou presque.
                                Par contre, j'apprécie d'avoir /etc/httpd/conf.d/ ou /etc/ld.so.conf.d/ etc.
                                Ça évite d'éditer /etc/httpd/conf/httpd.conf etc. Mais /etc/rc.d/rc.sysinit n'est _jamais_ édité (par les scripts d'installation de rpm par exemple).
                                • [^] # Re: Conseils ?

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

                                  "Mais /etc/rc.d/rc.sysinit n'est _jamais_ édité (par les scripts d'installation de rpm par exemple). "

                                  Oui, mais il peut etre mis a jour dans une update.
                                  Et si tu le modifie pour ajouter des truc, tu te retrouves a devoir mergé la correction du bug dans ton script vu que rpm a crée un .rpmnew.
                                  • [^] # Re: Conseils ?

                                    Posté par  . Évalué à 2.

                                    C'est pour ça qu'il y a rc.local.
                                    rc.local est vide à l'origine.
                                    Oops, c'est faux, il y "touch /var/lock/subsys/local" :-)

                                    Il y aura peut-être un .rpmnew pour rc.local mais tu peux l'ignorer (sûrement une mise à jour du commentaire dans le fichier). À moins que "touch /var/lock/subsys/local" soit buggé ou présente un trou de sécurité :-)

                                    Et tu peux toujours faire un script dans /etc/rc.d/init.d/ (ala Debian).

                                    Tu trouveras toujours un cas où il faut modifier rc.sysinit. Mais franchement, regardes les forums d'aide ou les mailings et tu verras qu'on ne propose pratiquement jamais de modifier rc.sysinit.

                                    Et si c'était le cas, Red Hat utiliserait un système type Debian.
                                    Ils ne sont pas cons :-)
                  • [^] # Re: Conseils ?

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


                    Ext3 est montrer comme un fs moderne et ce n'est pas le cas, comme le disait l'article de LinuxMag, c'est un fs de transition pour ext2. Mais sur une machine neuve, mieux vaut passer à quelques chose de mieux pensé.

                    Est-ce que ReiserFS est-il bien plus performant et plus fiable qu'Ext3 ?????????????
                    Si cela m'est démontré alors, j'admettrais que mon point de vue est caduque. Néanmoins, jusqu'à là c'est le choix de certains d'utiliser ext3.
                    De plus, la réponse à ma question ne semble pas encore bien claire...
                    Alors l'argument, c'est plus moderne, c'est mieux pensé, me fait franchement sourire... On dirait : "oh il me manque le dernier schmurff en vogue sur ma machine !!". Alors en effet, c'est peut-être la dernière feature à la mode, mais pour l'instant il ne semble pas que tout ce qui semble vitale aux entreprises est dans ReiserFS !

                    J'ai pas dit ext3 craint, j'ai dit ext2 craint. Je suis sur que la partie journalisation de ext3 est de bonne qualité mais le fs dessous(ext2) lui est tres basique. C'est un peu comme si Microsoft avait sortie la Fat 32++ (Fat 32 + journalisation + ACL) au lieu de NTFS ;)

                    J'en conclu que ext3 ne craint pas ;-)

                    Deja, tu enleves Mandrake vu que leur politique est de faire comme RedHat :) Il y'a plein de truc suxorisant dans la Mandrake qui sont la paske c'est comme ca chez RedHat: le rc.sysinit par exemple. Je sais je me repete ...au premier programme C d'un edudiant d'IUT premiere année.

                    Donc dire RedHat l'a choisit donc c'est une bonne solution, ca me fait sourire ;)

                    Ai-je dis cela ? J'ai dis que c'était _leur_ décision et qu'ils étaient compétents pour choisir si tel ou tel système de fichier correspond à leur attente.
                    Douterais-tu de leur compétence ? Es-tu meilleur que ces équipes de dev ? Tes arguments semblent convaincants, contactes RH (et MDK)...

                    Bonne journée.
                    Christophe
                    • [^] # Re: Conseils ?

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

                      "Si cela m'est démontré alors, j'admettrais que mon point de vue est caduque. "

                      GNU/Hurd a de moins bonnes perfs que GNU/Linux, pourtant GNU/Hurd est meilleur techniquement! Donc oui, ton point de vue est caduque ;) Et si tu regarde n'importe quel bench comparant XFS, reiserfs et ext3, XFS et Reiserfs seront tjs devant(avec des nuance entre les deux suivant le bench) et ext3 derriere. Par contre, ext2 lui est plus performant que tout les autres :) Mais rajouter la journalisation à quelque chose qui n'a pas été concu pour, ca donne pas de meilleurs perfs et en principe, il vaut mieux tout recommencer. Et de toute facon, ext3 est la pour la compatibilité, et pour cela c'est tres bien qu'il soit la!


                      "Douterais-tu de leur compétence ? Es-tu meilleur que ces équipes de dev ? Tes arguments semblent convaincants, contactes RH (et MDK)..."

                      Moi meilleur? mouahahah :) non :)
                      Mais bon, d'apres ce que j'ai compris(meme si je n'aime pas le rc.sysinit de RedHat), c'est plus problematique chez Mandrake qui met tout est n'importe quoi dans ce script(qui a depassé les 1000 lignes depuis un moment :) Ensuite, j'ai prevenu MandrakeSoft, si tu regardes la ml cooker, tu veras deux mail de moi sur le sujet à 6 mois d'intervalle(j'aim bien insister) mais bon, si ils veulent pas, je peux pas les forcer ;)
            • [^] # Re: Conseils ?

              Posté par  . Évalué à 5.

              > Maintenant faut voir en pratique parce que on a eu le même
              > discours avec la version 3 et pour être reparti de zéro faut
              > croire qu'il était pas si bien que ça.

              Mmmh... les objectifs de Reseir4 sont complètement différents, et il y a eu pour Reseir4 un paquet d'idées nouvelles, donc ça n'aurait pas eu grand sens de partir sur la base de ReseirFS 3. Mais ça ne prouve en rien que ReseirFS 3 était un échec ; qu'une boîte se lance dans un nouveau projet n'indique pas systématiquement qu'elle juge les pré précédents bons pour la poubelle.
          • [^] # Re: Conseils ?

            Posté par  . Évalué à 10.

            > Mwai, il n'empeche que ext3 n'a rien d'un fs moderne

            ???
            On peut dire qu'Unix n'a rien d'un OS moderne si on commence avec ce type d'argument.

            ext3 a toutes les fonctionnalités ou presque.
            lvm => ça marche
            acl => ça marche
            selinux => ça marche
            cluster type gfs => ça marche
            fiabilité => excellente

            Il lui manque ces petits trucs (mais techniquement difficile à réaliser) qui permet de gagner 2 à 3 % en perfo en usage typique et à fiabilité équivalente. Le problème des benchs est qu'ils sont rarement fait à niveau de fiabilité équivalent. Ils sont concentrés sur les performances.

            > Je trouve juste dommage que redhat/mdk restent bloqués sur ce fs juste pour une histoire de compatibilité ext2.

            Red Hat a largement démontré qu'ils n'hésite pas à ignorer la compatibilité si ça va dans le bon sens.
            Red Hat est dédié serveur et leurs utilisateurs sont plus proches des administrateurs que des hobbystes.
            La compatibilité c'est bien, mais s'il faut casser la compatibilité pour avoir meilleur, il le feront.

            > redhat aime bien ext3 pour des raison techniques mais qui ne concerne que la journalisation.

            Pas que ça. RedHat a aussi une floppée de tests (fiabilité, tenue en charge, fonctionnalité, etc) et ext3 les passes tous ce qui n'est pas le cas de reiserfs. Parole d'Alan Cox. NB : vrai pour Linux 2.4, j'ai pas d'info pour Linux 2.6.

            Si Reiserfs4 est techniquement excellent (et aussi dans la pratique :-)), complet (un fsck qui roxor aussi), performant, fiable, etc, ajoutes 6/12 mois pour que le tout soit rock solide et Red Hat utilisera reiserfs.

            Puis il faut arrêter de pointer Red Hat comme un méchant qui ne veut pas utiliser reiserfs. ext3 est aussi le fs le plus utilisé par les développeurs Linux.
            En gros, Red Hat fait comme la majorité des développeurs.

            J'ai lu beaucoup de bien de reiserfs v4. Si c'est pas du pipo publicitaire (comme reiserfs v3), ou pour draguer les filles en discothèque, reiserfs v4 passera devant ext3 (toutes distributions confondues).

            Que je sache, Linux est un logiciel libre et ce sont les meilleurs solutions qui s'imposent. Les préférences de Red Hat ne change rien à ça (au moins à long terme).

            SVP : arrêtez avec le complot RedHat/mdk (Pourquoi tu parles de mdk?) pour empêcher l'"envol" de reiserfs.
            • [^] # Re: Conseils ?

              Posté par  . Évalué à 3.

              EXT2/3 a une limitation pesante dans certaines situations comparé aux autres FS standards de Linux, c'est sa gestion antédiluvienne, pour le coup, des inodes. Devoir encore formatter de manière particulière sa partition pour avoir un nombre fixe d'inodes est une restriction qui commence à se faire pesante quand tu dois travailler dans un environnement avec des arborescences profondes et un grand nombre de fichiers.
              C'est probablement la seule vraie limitation que je lui vois, mais elle va de pair avec sa relative lenteur sur de répertoires avec beaucoup de petits fichiers. Je trouve également pesant de perdre aux alentours de 10% de ma partition pour le journal.
              En ce qui me concerne, je trouve Ext3 bien mais ReiserFS3 mieux, donc j'utilise Reiser. Donc j'évite Red Hat (mais ça j'aurais évité de toutes les façons).

              Richard
              • [^] # Re: Conseils ?

                Posté par  . Évalué à 4.

                > Devoir encore formatter de manière particulière sa partition pour avoir un nombre fixe d'inodes est une restriction qui commence à se faire pesante

                Ouais. Mais c'est rare les gens qui sont limités par la valeur par défaut lors du formatage.
                En gros, une partition de 20 Go donne 2 500 000 inode !

                J'ai jamais vu sur un forum quelqu'un demander à augmenter le nombre d'inode d'une partion ext3...

                > quand tu dois travailler dans un environnement avec des arborescences profondes et un grand nombre de fichiers.

                man tune2fs :
                  dir_index
                  Use hashed b-trees to speed up lookups in large
                  directories.

                  sparse_super
                  Limit the number of backup superblocks to save space
                  on large filesystems.

                sparse_super évite d'avoir 40 superblocks à mettre à jour. La profondeur ne change rien puisque le répertoire est repéré par l'inode.

                man e2fsck :
                  -D
                  Optimize directories in filesystem. This option causes e2fsck
                  to try to optimize all directories, either by reindexing them if
                  the filesystem supports directory indexing, or by sorting and
                  compressing directories for smaller directories, or for filesys-
                  tems using traditional linear directories.

                > Je trouve également pesant de perdre aux alentours de 10% de ma partition pour le journal.

                Où tu as vu ça ?

                Exemple avec une partition de 120 Go :
                # cat /proc/partitions
                major minor #blocks name
                9 0 120372992 md0

                # df /dev/md0
                Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
                /dev/md0 120111456 70477292 49634164 59% /

                # bc
                (120372992-120111456)/120372992*100
                .21727132

                261536 blocks de 1k pour le FS uniquement.
                Un peu plus de 0,2 % de blocs de 1K utilisé pour la gestion d'ext3. Imaginons qu'au pire de l'utilisation je monte à 0,5 % (faut beaucoup d'imagination...).

                man mke2fs :
                  size=journal-size
                  Create an internal journal (i.e., stored inside the
                  filesystem) of size journal-size megabytes. The
                  size of the journal must be at least 1024 filesystem
                  blocks (i.e., 1MB if using 1k blocks, 4MB if using
                  4k blocks, etc.) and may be no more than 102,400
                  filesystem blocks.


                On est très très loin de tes 10 %.

                Tu ne confond pas avec les "Reserved blocks" qui est configurable avec "tune2fs|mke2fs -m" ? Pour les "Reserved blocks", c'est 10 % par défaut.
                Utilises "tune2fs|mke2fs -m 0 /dev/partition".
                • [^] # Re: Conseils ?

                  Posté par  . Évalué à 2.

                  Sur mon bête poste de travail, je suis déjà à 630000 inodes utilisés. Je parlais bien de certaines situations : je fais de la sauvegarde et je suis régulièrement confronté à des clients qui ont des répertoires avec des millions de fichiers temporaires sur leurs serveurs. C'est typiquement le cas où cela pose un problème.
                  D'autre part, c'est très bien de pouvoir tuner EXT3 pour certains usages spécifiques mais j'imagine que du coup, ils sont moins efficaces sur d'autres usages. Tant qu'à faire je préfère le système de fichiers qui me fournit tous ces avantages sans inconvénients par défaut.
                  Pour la taille du journal, je n'avais qu'une petite partition comme référence, donc effectivement, c'est un mauvais argument.

                  Richard
                  • [^] # Re: Conseils ?

                    Posté par  . Évalué à 1.

                    > Je parlais bien de certaines situations : je fais de la sauvegarde et je suis régulièrement confronté à des clients qui ont des répertoires avec des millions de fichiers temporaires sur leurs serveurs.

                    Temporaires ?!?
                    Il y a un problème alors.

                    M'enfin, en gros avec les paramètres par défaut, il y a 1 inodes pour 2 à 3 blocks.
                    Le maxi est 1 inodes par block (pour reiserfs ça doit aussi être le cas).
                    Bref, il faut vraiment en vouloir pour atteindre la limite de la valeur par défaut.
                    Je ne dis pas que ça n'arrive pas. Mais ça doit être rare.

                    Rendre la taille de la table des inodes dynamique est dans la TODO list. Ça passera peut-être par par un "umount ... ; tune2fs ... ; e2fsck (peut-être) ; mount".

                    Pas de délais annoncé.
            • [^] # Re: Conseils ?

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

              "On peut dire qu'Unix n'a rien d'un OS moderne si on commence avec ce type d'argument."

              Oui, c'est le cas ;) Ca m'empeche pas de l'utiliser mais je sais tres bien que Unix est loin d'etre parfait. Mais moi au moins je l'avoue :p

              "SVP : arrêtez avec le complot RedHat/mdk (Pourquoi tu parles de mdk?) pour empêcher l'"envol" de reiserfs. "

              Je parle de Mandrake parce que... Ben c'est expliqué deux commantaires plus haut ;) Mandrake a peur de s'eloigner de RedHat. C'est l'argument choc que l'on m'a sortie quand j'ai proposé aux devels de chez mdk de repenser leur init afin d'avoir quelque chose de plus modulaire.
              • [^] # Re: Conseils ?

                Posté par  . Évalué à 2.

                > Mandrake a peur de s'eloigner de RedHat. C'est l'argument choc que l'on m'a sortie

                Pour reiserfs, il y a de grosses différences entre RedHat et Mandrake :
                - RedHat/Fedora ne propose pas de façon claire reiserfs. Il faut savoir qu'il faut taper "linux reiserfs" à l'invite de l'installation sinon reiserfs n'est pas proposé (idem pour jfs, xfs, etc).
                - reiserfs n'est pas supporté par RHEL. Si t'es emmerdé par reiserfs, inutile d'appeler le support RH.
                - RedHat (moins pour Fedora) ne fait pas l'effort de patché leur noyau avec les derniers bugfix de reiserfs. Il y a que ext3 qui est "soigné".

                T'es un injuste sur ce coup avec Mandrake.
                • [^] # Re: Conseils ?

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

                  Oui, mais la c'est cosmetique, le choix par defaut de Mandrake, c'est ext3.

                  "Si Reiserfs4 est techniquement excellent (et aussi dans la pratique :-)), complet (un fsck qui roxor aussi), performant, fiable, etc, ajoutes 6/12 mois pour que le tout soit rock solide et Red Hat utilisera reiserfs."

                  Désolé pour ce croisement de commentaire, c'est mal :)

                  Mais, XFS est la depuis longtemps, stable et a fait ses preuves chez SGI. Depuis le 2.6.0, il est officiellement dans le noyau et pourtant la fedora ne l'utilise pas par defaut. Pourquoi? :)

                  Et vu que tu as l'air de croire que je suis un grand fan de reiserfs, c'est pas du tout le cas, mon fs favoris, c'est XFS ;)
                  • [^] # Re: Conseils ?

                    Posté par  . Évalué à 3.

                    > Depuis le 2.6.0, il est officiellement dans le noyau et pourtant la fedora ne l'utilise pas par defaut. Pourquoi? :)

                    C'est une bonne question.
                    Déjà, XFS est moins fiable. Je ne dis pas qu'il est codé avec les pieds mais il n'a pas le mode data=ordered d'ext3.
                    Voir aussi :
                    http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034.(...)
                      The ext3 have almost a perfect record with the write cache off: I have run over 300 cycles on the two drives and only had two corrupted lines in the output files. So out of 600 total cycles on the two drives there were only two lines with bad data, I think that is a pretty good record.

                      None of the other journaling file systems have come anywhere near this performance. After 3 or 4 power cycles, ReiserFS became corrupted to the point that the system would not boot up (the fsck failed and the bootup stopped there). XFS never got corrupted to the point it wouldn't boot, but with approximately 100 power cycles on each drive, one drive had 73 corrupted lines and the other had 82. With JFS after 15 power cycles one of the drives was corrupted and the system would no longer boot up (fsck failed again).


                    Enfin, et ce point est important bien que souvent ignoré, Red Hat a des compétences en ext3.
                    S'il y a des problèmes avec xfs, RedHat n'a pas forcément les compétences en interne pour corriger ou expertiser rapidement le problème.

                    Si tu veux du reiserfs, prend du SuSE, ils ont les compétence. Pour ext3, regardes du côté de Red Hat. Pour XFS, install Irix :-)

                    Un distributeur ne peut pas avoir des compétences sur tous les FS. Surtout qu'avec toutes les combinaisons (FS/lvm/raid/acl/nfs/GFS) ça devient très très vite l'enfer pour tout tester si tu supports tous les FS (ext3, xfs, jfs, reiser3, reiser4, etc).

                    > mon fs favoris, c'est XFS ;)

                    Le mien, ext3. Principalement car il est fiable, il me suffit, il est en standard avec ma distrib (Je n'ai pas à récupérer de patch, etc) et j'ai pas envie de me prendre la tête pour gagne 0,2 % en perfo ou place disque.
                    Je suis fainéant et j'ai jamais pris le temps de tester les différents FS dispos sous Linux.
              • [^] # Re: Conseils ?

                Posté par  . Évalué à 3.

                Je crois que tu confonds modernité et efficacité. Une technologie peut être ancienne et parfaitement efficace et évoluer avec le temps.

                Le cas d'Unix me semble justement un trés bon exemple. Des bonnes fondations ont permis au système de s'améliorer au fil des années et ce sans renier son passé. Certains OS supposés plus modernes que Linux/Unix ne parviennent pas forcément à le supasser dans biens de domaines. Unix n'est certes toujours pas parfait, mais à ma connaissance aucun OS ne l'est (fort heureusement!).

                En ce qui concerne les systèmes de fichiers, les benchs de tests ne sont que très peu révélateurs de l'efficacité réelle du FS. La fiabilité me semble absolument primordiale. Malheureusement cette donnée n'est pratiquement jamais testée. Dans ce domaine, ReiserFS 3 avait peu convaincu (d'ou à mon avis son manque de succès), J'espère que la version 4 sera plus performante de ce coté. Rdv dans 1 an...
                • [^] # Re: Conseils ?

                  Posté par  . Évalué à 1.

                  Moderne ce dit de quelque chose utilisé actuellement.
                  Une fourchette est moderne.
                  MS-DOS n'est pas moderne.
                  Unix est moderne depuis 30 ans :-)
                  • [^] # Re: Conseils ?

                    Posté par  . Évalué à 2.

                    Absolument pas.

                    Moderne se dit d'une chose utilisé depuis peu, et se dit aussi d'une chose utilisant des concepts novateur.

                    Une fourchette n'est pas moderne.
                    La base d'Unix n'est pas moderne, mais le kernel 2.6 par exemple est moderne.
                    etc...

                    Maintenant, comme tu le dit si bien, il existe des choses que l'on ne peut qualifié de moderne (une fourchette) qui n'ont pourtant pas trouvé de meilleur remplaçant...

                    Comme quoi la modernité et l'efficacité sont deux concepts distincts.
                    • [^] # Re: Conseils ?

                      Posté par  . Évalué à 2.

                      > Moderne se dit d'une chose utilisé depuis peu

                      La voiture et le metro ne sont pas des modes de transport modernes ?

                      http://colet.uchicago.edu/cgi-bin/dico1look.pl?strippedhw=MODERNE(...)
                      La dernière définition de Académie française :
                      Qui est soit de notre temps, soit d'un temps plus ou moins rapproché du nôtre, par opposition à Antique, à ancien.

                      Unix est de notre temps. MS-DOS non et pourtant il est moins vieux d'Unix.
                      Linux 2.6 est d'un temps rapproché du nôtre, par opposition à Unix qui est un ancien.

                      Unix est moderne (de notre temps).
                      Linux est moderne ET moderne (de notre temps ET non ancien).
                      • [^] # Re: Conseils ?

                        Posté par  . Évalué à 2.

                        Moderne est un adjectif. Il qualifie une action, une utilisation, un concept, une idée, une technique, etc.

                        utilisation moderne => utilisé depuis peu
                        conception moderne => conçu depuis peu

                        Cela signifie qu'un objet peut être de conception ancienne (donc non moderne) et d'utilisation moderne.

                        Le 'depuis peu' exprime une durée relative à l'espace de temps dans lequel on se situe.

                        La création d'Unix est donc ancienne (à l'échelle de l'infomatique). En revanche, de nouvelles techniques sont ajoutées chaque jour a linux. On pourrait donc dire que Linux est un os moderne dont les origines sont anciennes...

                        Bref tout cela c'est pas simple ....
                      • [^] # Re: Conseils ?

                        Posté par  . Évalué à 2.

                        Le metro est moderne si l'on prend comme total temps toutes la période ou des transports furent utilisé, ce qui commence à la chaise à porteurs, a peu prêt et donc effectivement, par rapport à ceci le metro est moderne. Mais si on prend comme raltif temps les inventions de notre génération, c'est à dire des 10 dernières années en gros, le metro n'est clairement pas moderne.

                        C'est pareil pour l'informatique, Unix n'est absolument pas plus moderne que MS DOS. La base de Linux n'est pas moderne non plus, car au vu de l'ancienneté de l'informatique domestique, cela fait longtemps qu'il a vu le jour. Mais comme je le disais, certains concepts de Linux sont moderne.

                        Tu confond de notre temps (de notre époque) à "utilisé encore actuellement", ce qui est totalement différent, la fourchette est bien encore utilisé actuellement...
                        • [^] # Re: Conseils ?

                          Posté par  . Évalué à 1.

                          ????
                          Unix (n')est (pas) de notre temps.
                          Unix (n')est (pas) utilisé encore actuellement.

                          J'y comprend rien.
                          Il me semble, et j'ai peu de doute sur ça, qu'Unix est de notre temps et est encore utilisé.
                          Unix se trouve facilement aujourd'hui (OS, articles, etc...). Il est donc de notre temps.
                          Unix est utilisé.

                          > Unix n'est absolument pas plus moderne que MS DOS.

                          Impressionnant.
                          • [^] # Re: Conseils ?

                            Posté par  . Évalué à 2.

                            Moderne ne veut pas dire utilisé actuellement et ne pas être moderne ne veut pas dire plus utilisé (exemple, encore, la fourchette).

                            Enfin bref, nous n'avons pas la même perception des choses et tu essaye de raisonner avec une explication litéraire.

                            Mais je persiste et signe, et je pense que tu pourrais demander à ton entourage (en leur donnant des dates) pour qu'ils te disent ce qu'ils en pensent, tu es dans l'erreur.
                            • [^] # Re: Conseils ?

                              Posté par  . Évalué à 1.

                              > tu essaye de raisonner avec une explication litéraire.

                              Je fais de mon mieux pour parler français et pas la banlieu.
                              Alors ziva, lâche moi la grappe :-)

                              Sinon j'ai mon "micro robert" (pas très litéraire...).
                              Moderne :
                              1- Actuel, contemporain, récent
                              2- Qui bénéficie des progrès récents, correspond au goût actuel
                              3- (personnes) qui tient compte de l'évolution récente dans son domaine

                              Le 1 et le 2 me conviennent. Le 3 pour les personnes me convient aussi.
                              Unix tombe en 1 et Linux plutôt en 2.
                              Tu préfères ne retenir que le 2.

                              Le français étant une langue vivante, je ne vais pas te le reprocher.
                              • [^] # Re: Conseils ?

                                Posté par  . Évalué à 2.

                                Dans le 1 il y a récent et c'est quand même très important. Et justement, si l'on prend Unix, il n'est absolument pas recent, voir même moins que MS DOS par ailleur.

                                Ensuite, Unix et même Linux n'ont rien de contemporain, un OS contemporain serait Windows ou MacOSX ou Pegasos etc, mais surement pas Unix qui date de la décennie précédente. Et encore une fois, le fait qu'il soit utilisé et qu'il convienne parfaitement à nombre d'utilisation ne veut pas dire qu'il soit moderne.


                                Le français étant une langue vivante, je ne vais pas te le reprocher.

                                Justement, c'est pour cela qu'il ne faut pas se baser sur un sens littéraire, le Français bouge et si tu prend un dictionnaire de 1920, tu serais bien surpris de la définition qu'avaient certains mots...

                                Le débât est sans fin et l'on trouvera des partisants des deux cotés, mais pour moi Unix n'est pas moderne, même si c'est l'OS que je préfére et qui me correspond le mieux.
                                • [^] # Re: Conseils ?

                                  Posté par  . Évalué à 1.

                                  > un OS contemporain serait Windows ou MacOSX ou Pegasos etc

                                  Après MS-DOS plus moderne qu'Unix...
                                  btw, Unix a implémenté Internet (ipv4, mail, ftp, uucp, etc) bien avant Windows.
                                  Le modèle ouvert d'Unix (normes) et le modèle open-source de Linux (et pourtant l'idée est vieille...) et beaucoup plus moderne/novateur que le modèle fermé basé sur l'exclusivité et capitaliste de Windows. C'est d'ailleur tellement "moderne" que beaucoup de journalistes et politiciens ne l'ont pas encore intégré.

                                  > Justement, c'est pour cela qu'il ne faut pas se baser sur un sens littéraire
                                  > un dictionnaire de 1920

                                  Pour être honnète, tu m'énerves un peu.
                                  1- Je n'ai pas pris un dico de littérature.
                                  2- Mon "Robert" date de 1997 (c'est vieu mais c'est correct).
                                  3- Toi et/ou ton quartier n'est pas forcément la meilleur référence pour le Français.

                                  Désolé.
                                  • [^] # Re: Conseils ?

                                    Posté par  . Évalué à 2.

                                    btw, Unix a implémenté Internet (ipv4, mail, ftp, uucp, etc) bien avant Windows.

                                    Il y a 10 ans voir même 5 ans c'était un OS moderne :-)

                                    Le modèle ouvert d'Unix (normes) et le modèle open-source de Linux (et pourtant l'idée est vieille...) et beaucoup plus moderne/novateur que le modèle fermé basé sur l'exclusivité et capitaliste de Windows. C'est d'ailleur tellement "moderne" que beaucoup de journalistes et politiciens ne l'ont pas encore intégré.

                                    Oui enfin à noter quand même que le modèle n'est pas une invention de l'Open Source :-)


                                    Pour être honnète, tu m'énerves un peu.
                                    1- Je n'ai pas pris un dico de littérature.
                                    2- Mon "Robert" date de 1997 (c'est vieu mais c'est correct).
                                    3- Toi et/ou ton quartier n'est pas forcément la meilleur référence pour le Français.


                                    ça n'émpèche en rien que qualifié Unix d'OS moderne, en 2004, est faux. Mais Unix (ou plutôt Linux) est un OS contenant des concepts modernes. C'est toute la différence :-)

                                    Mais bref, peut importe.
                                    • [^] # Re: Conseils ?

                                      Posté par  . Évalué à 1.

                                      > Mais bref, peut importe.

                                      Oui. Mais un petit truc. Je ne pense pas que la modernité se mesure sur une ou deux années.
                                      Internet à plus de 20 ans et c'est depuis fin 90 que ça conserne nos "contemporains".
                                      C'est depuis 2 ans environ que beaucoup de foyer français ont Internet.
                                      L'accès à Internet, l'utilisation d'Internet, ses conséquences, etc reste un point chaud et le moins qu'on puisse dire, c'est que ça reste globalement opaque pour le citoyen moyen et pire encore pour les politiciens/journalistes et même pour les spécialistes (qui par exemple n'ont pas vu venir Internet ni Linux et un fois sur deux disent des conneries).

                                      Pour ma part, tout ce qui conserne l'informatique et qui est utilisé actuellement est moderne (même en insistant sur "récent").
                                      • [^] # Mur

                                        Posté par  . Évalué à 2.


                                        Oui. Mais un petit truc. Je ne pense pas que la modernité se mesure sur une ou deux années.


                                        C'est une question de contexte et de relativité. Sur quelque chose comme les transport qui évolue lentement, clairement pas. Sur quelque chose comme l'informatique qui évolue très vite, ta modernité d'il y a deux ans peut être complétement dépassé.




                                        C'est depuis 2 ans environ que beaucoup de foyer français ont Internet.
                                        L'accès à Internet, l'utilisation d'Internet, ses conséquences, etc reste un point chaud et le moins qu'on puisse dire, c'est que ça reste globalement opaque pour le citoyen moyen et pire encore pour les politiciens/journalistes et même pour les spécialistes (qui par exemple n'ont pas vu venir Internet ni Linux et un fois sur deux disent des conneries).


                                        Aucun rapport, on juge une modernité (ou autre) sur un aspect globale de création, pas de démocratisation massive. De toute façon, dès que ça devient démocratisé, c'est moins moderne. Exemple l'Ipod, c'est moderne, mais tout le monde n'en a pas. Le téléphone portable, c'est plus vraiment moderne (ça date) et maintenant tout le monde ou presque en as.

                                        Pour les "spécialistes", ils ont, tout au long de l'histoires, pratiquement jamais rien vu arrivé alors il ne faut pas trop s'en étonner pour le LL.


                                        Pour ma part, tout ce qui conserne l'informatique et qui est utilisé actuellement est moderne (même en insistant sur "récent").


                                        J'ai bien compris ton point de vue et tu reste opaque au miens et à mes arguments :

                                        Etre utilisé actuellement ne veut pas dire être moderne. Exemple un browser n'est pas moderne, le concept est vieux. Par contre le css et le xml sont des concepts modernes. Bien qu'ils commencent à le devenir un peu moins avec le temps...

                                        Bref, encore bref, Unix n'est pas moderne (il date d'au moins 1990) (je n'ai plus de date en tête) et 14 ans, c'est énorme en informatique. Mais, encore une fois, certains concepts de Linux sont modernes.
                                        • [^] # Re: Mur

                                          Posté par  . Évalué à 1.

                                          > Par contre le css et le xml sont des concepts modernes.

                                          Selon ta définition, non.
                                          C'est SGML en plus simple et SGML date de 15 ou 20 ans (j'ai oublié).
                                          Pour css, la séparation de la présentation et des données est un très vieux concept aussi.

                                          > Unix n'est pas moderne (il date d'au moins 1990)

                                          Rires...
                                          Unix, même époque que le language C. C-à-d fin 60 début 70.

                                          > et 14 ans, c'est énorme en informatique

                                          L'informatique en est encore à ses débuts. Au début de l'aviation ou de l'automobile, 14 ans c'était énorme aussi.
                                          Tu peux aussi affirmer que l'avion n'est pas un mode de transport moderne alors.

                                          > certains concepts de Linux sont modernes.

                                          En fait, très peu. En tout cas pour l'utilisateur final. Si tu sais utiliser Unix tu n'es pas dépaysé sous Linux et vice versa.
                                          • [^] # Re: Mur

                                            Posté par  . Évalué à 1.

                                            [Suite]

                                            Ça fait depuis 9 ans (dans 6 mois, ça fera 10 ans) que j'utilise ce vieux Linux :-)

                                            http://www.linuxjournal.com/article.php?sid=6000(...)
                                            Slackware : juin 93
                                            Linux 1.0 : mars 94 (+ de 10 ans)
                                          • [^] # Re: Mur

                                            Posté par  . Évalué à 1.

                                            Grrr

                                            > Unix, même époque que le language C. C-à-d fin 60 début 70.

                                            Début développement. Premières versions vraiment exploitables en 73-75.
                                          • [^] # Re: Mur

                                            Posté par  . Évalué à 2.


                                            Selon ta définition, non.
                                            C'est SGML en plus simple et SGML date de 15 ou 20 ans (j'ai oublié).
                                            Pour css, la séparation de la présentation et des données est un très vieux concept aussi.


                                            Alors ce n'est pas moderne :-)


                                            Rires...
                                            Unix, même époque que le language C. C-à-d fin 60 début 70.


                                            D'ou le au moins, la recherche de date n'est qu'une vague recherche sur google dont j'avais la flemme. C'est donc dire si vraiment c'est vieux...


                                            L'informatique en est encore à ses débuts. Au début de l'aviation ou de l'automobile, 14 ans c'était énorme aussi.
                                            Tu peux aussi affirmer que l'avion n'est pas un mode de transport moderne alors.


                                            ça dépend, l'avio a réaction oui, l'avion à hélice un peu moins :)


                                            En fait, très peu. En tout cas pour l'utilisateur final. Si tu sais utiliser Unix tu n'es pas dépaysé sous Linux et vice versa.

                                            Il s'agit d'avantage de concept concernant la gestion matériel etc, pas concernant l'aspect end user.
          • [^] # Humour

            Posté par  . Évalué à 1.

            Oui, mais de toute facon, la conception de Linux avec son noyau monolithique n'a rien de moderne , si tu cherche des solutions modernes tu n'a qu'a utiliser W2000 et NTFS
            • [^] # Re: Humour

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

              "si tu cherche des solutions modernes tu n'a qu'a utiliser W2000"

              Oui, mais Windows 2000 n'a rien de moderne ;) Un pseudo µkernel avec tout et n'importe quoi dedans. Quand tu entends des gens de chez Microsoft dire que la difference entre X et GDI, c'est que X est un programme comme les autres sous Linux alors que GDI "est en mode noyau" (veridique, si quelqu'un a tjs le lien de l'interview du mec de chez MS, passé sur OSnews je pense).

              Donc win2k, OS moderne, ah ah ah :)

              Tu aurais dit QNX, ok, j'aurais rien dit ;)
              • [^] # Re: Humour

                Posté par  . Évalué à 1.

                J'avoue ma meconnaissance des arcanes de la conception des OS, mais pour pousuivre dans la même veine que mon poste de départ il est certain que j'aurais du parler de Minix et non de W2000 toutes mes excuses
            • [^] # Re: Humour

              Posté par  . Évalué à 3.

              HURD, voila un truc qui est basé sur un micro-kernel (donc moderne, donc bon, donc que tout le monde utilise ). C'est juste non ?
      • [^] # Re: Conseils ?

        Posté par  . Évalué à 4.

        > http://jfenal.free.fr/Traduc/LG55D/lg55d-fr/lg55d-fr-4.html(...)

        N'est absolument pas à jour et parfois faux.

        ext3 c'est 16 To par partition et 4To par fichier (et pas 2Go !).
        ext3 supporte les "fichier à trous" (ext2 aussi je crois).

        ext3 peut stocker les liens symboliques dans l'inode (ext2 aussi, d'ailleur c'est ext2 qui a implémenté ça en premier).

        Les gestions des bloques libres est un peu plus subtile que ce que décrit l'articles (il y a des groupes).

        Pour "Gestion d'un grand nombre d'entrées de répertoire", c'est encore un peu plus subtile que ce qu'avance l'article. Si un répertoire a l'attribut 'I' (Indexed directory) il y a un index pour le répertoire. Il n'y a pas l'attribut 'I' pour tous les répertoires car ça ralentit (on voit ça aussi pour les bases de données). On peut utiliser fsck pour optimiser les répertoires et mettre automatiquement l'attribut 'I' aux répertoires suffisament importants pour que l'indexation améliore en performance.
        NB : l'indexation est désactivée par défaut (pour l'ensemble du FS et par répertoire) ! Alors forcément, les benchs ne sont pas terribles (même les benchs qui prétendent utiliser htree).
        Htree en action : http://lwn.net/Articles/14631/(...)

        Ext3 n'est pas adapté aux petits fichiers ?
        Pourquoi pas. Mais reiserfs avec le mode tail activé n'est pas rapide (il se fait "bouffé" en performance par ext3). Les benchs reiserfs sont en général avec notail (comme ext3).

        > ext3 ne fait que rajouter la journalisation à l'antidéluvien système de fichier ext2

        - et les attribut étendu.
        - et ACL.
        - et les "security label" (pour SeLinux)
        - et les quota v2.
        - et htree.
        - et les fichiers de 4 To.
        - et la journalisation la plus sûre actuellement tout système de fichier confondu (journalisation des meta-données et des données en même temps).
        - et sparse_super
        - et le resize à chaud
        - e2fsprogs est maintenu par Theodore Ts'o et ça en fait une suite particuliairement fiable et sympatique (e2image, badblocks, dumpe2fs, debugfs, etc).
        - et ... rien, mais rappelons que ça reste le système de fichier le plus fiable et que les bugs y sont rares. A utiliser les yeux fermés. Tout le monde ne peut pas en dire autant.

        ext3 n'est pas mort. Pas pour cette année au moins.
        • [^] # Re: Conseils ?

          Posté par  . Évalué à 1.

          > ext3 peut stocker les liens symboliques dans l'inode (ext2 aussi, d'ailleur c'est ext2 qui a implémenté ça en premier).

          http://e2fsprogs.sourceforge.net/ext2intro.html(...)
          Ext2fs implements fast symbolic links. A fast symbolic link does not use any data block on the filesystem. The target name is not stored in a data block but in the inode itself.
        • [^] # Re: Conseils ?

          Posté par  . Évalué à 2.

          > N'est absolument pas à jour

          On va de surprise en surprise. C'est une traduction d'un article qu'on trouve dans un linux Gazette de juillet 2000 ! plus de 4 ans !
          http://www.linuxgazette.com/issue55/index.html(...)
    • [^] # Re: Conseils ?

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

      Personnellement, j'ai eu beaucoup de probleme avec ext3, je dois dire que j'ai pas souvent connu des crashs violent bien récupérés par ext3.

      Quand je dis ca il faut comprendre un crash(coupure de courant le plus souvent) a un moment ou le pc etait actif(urpmi en fonctionnement, ...).

      Avec reiserfs et xfs, meme si j'ai eu quelque probleme, c'etait rarement dramatique. Le seul truc que je peux dire, c'est que le plus rapide pour relire son journal, c'est xfs par contre :)

      Actuellement j'ai tout en xfs et mon / en reiserfs : le suse 9.1 a un probleme avec xfs et son noyau d'install.
    • [^] # Re: Conseils ?

      Posté par  . Évalué à 10.

      Chez moi, c'est simple :
      - ext3 à tous les étage en mode ordered (que ne fait pas reiserfs il me semble).

      Pour un usage desktop, reiserfs ou ext3, ça ne change rien. C'est le cache qui compte.
      => ajoute de la mémoire :-)

      > - la partition qui contient mes rushes videos DV (entre 150 et 400Mo le fichier)

      Là, c'est simple encore, utilises un bon disque.
      => Change de disque :-)

      Ici j'ai une grosse partition root en raid 0 stripé sur deux disques dure IDE.
      Le FS : ext3
      Débit écriture brute : 80 Mo/s
      Débit écriture ext3 : 70 Mo/s
      Débit lecture brute : 100 Mo/s
      Débit lecture ext3 : 80 Mo/s

      Bref, les disques comptent plus que le FS.

      Sinon, il me semble que reiserfs v4 n'a toujours pas de fsck (c'est très génant).

      Pour info :
      Pourquoi ext3 roxor en fiabilité selon Fedora/RH (si write cache disabled pour les DD) :
      http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034.(...)
      Le début de ce long thread :
      http://www.redhat.com/archives/fedora-test-list/2004-April/msg02646(...)
      Les modes ext3 :
      http://www.redhat.com/archives/fedora-test-list/2004-July/msg00036.(...)
      NB : ça ne parle pas de reiserfs V4.

      Conclusion (pour moi) :
      Hors de question de passer à reiserfs v4 sans fsck !
      Hors de question de passer à reiserfs v4 s'il est moins fiable que ext3 sur le papier (mode data=ordered).
      Attendre au moins 6 mois après l'intégration dans Linux pour mes donnés "importantes" (en gros tout sauf /tmp :-)) pour qu'il soit aussi fiable dans la pratique qu'ext3.

      J'ai le temps...

      Une chose est sûre, Reiserfs va encore faire du bruit. J'espère que ça ne va pas me saoûler comme pour la version 3... Si on écoute les zealot, ext3 n'existerait déjà plus.
      • [^] # Re: Conseils ?

        Posté par  . Évalué à 5.

        un rapide 'apt-cache show reiser4progs' montre les applications suivantes:

        - debugfs.reiser4
        - cpfs.reiser4
        - fsck.reiser4
        - measurefs.reiser4
        - mkfs.reiser4
        - resizefs.reiser4

        Donc, si, reiserfs v4 a un fsck, et pour répondre à d'autres questions, si il a aussi un resizefs.

        Par contre au vu des derniers commentaires sur la ML du kernel, il y a beaucoup de problèmes potentiels (par exemple reiser v4 ne respecte pas le comportement du flag O_DIRECTORY sur un open(), ce qui peut être TRES génant).
        • [^] # Re: Conseils ?

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

          > par exemple reiser v4 ne respecte pas le comportement du flag O_DIRECTORY sur un open(), ce qui peut être TRES génant

          Euh... je sais pas de quoi tu parles là... (et je pense ne pas être le seul... ;-) Tu peux nous en dire plus stp ? Quelles sont les implications/incompatibilités ?
        • [^] # Re: Conseils ?

          Posté par  . Évalué à 7.

          > - fsck.reiser4

          Tu as raison.

          Et quand on lance fsck.reiser4 on a :
            *******************************************************************
            This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
            *******************************************************************


          Et dans le README :
            FSCK.REISER4 WARNING

            This is an experimental software yet, MAKE A BACKUP BEFORE USING IT! Do not
            run rebuild unless something is broken. If you have bad sectors on a drive
            it is usually a bad idea to continue using it. Then you probably should get
            a working hard drive, copy the file system from the bad drive to the good
            one -- dd_rescue is a good tool for that -- and only then run this program.


          Ça fait penser au début de reiserfs V3 où la meilleur méthode pour corriger un fs corrompu a longtemps été mkreiserfs...

          Un fs sans fsck correcte ne mérite pas d'être numéroté 1.0.0.
          • [^] # Re: Conseils ?

            Posté par  . Évalué à 3.

            Un fs sans fsck correcte ne mérite pas d'être numéroté 1.0.0.


            Tout a fait !

            Je suis d'ailleurs bien surpris de voir que reiserfs v4 "sort" officielement, alors qu'aucun test serieux effectué par les developpeurs du noyau n'a été fait (par test serieux je n'entends pas test de perfs, mais plus test de fonctionnalités et revue du code).

            Il semble aussi que reiser v4 a été developpé sans aucune coordination avec les autres filesystems, et surtout sans respecter les API. C'est pour cette raison que plusieurs developpeurs ont demandé que cette version ne soit pas intégrée au noyau tant que les problèmes ne sont pas corrigés.

            Honnetement je doute que reiser v4 soit plus utilisable que pour du test en ce moment, en tout cas je ne l'utiliserait pas en prod :)
    • [^] # Re: Conseils ?

      Posté par  . Évalué à 2.

      voici comment j'ai fais chez moi, mais ca n'est valable que si tu n'installe pas des nouveaux soft régulièrement sous /usr
      - j'ai mis /usr et /usr/local en ext2, mais en ro seulement !
      comme ca, meme en cas de plantage, pas de pb puisque le fs est en ro.

      + avantage : comme la plupart des soft et lib sont sous /usr et que ext2 est plus rapide, ca se lance "en principe" plus vite; mais surtout, en cas de plantage, ca évite de corrompre quoi que ce soit
      - inconvénients : avant d'installer un truc sur /usr, il faut faire un mount /dev/xxx /usr -o remount,rw et aprés l'install, un mount /dev/xxx /usr -o remount,ro

      - xfs sur les autres partoches
      • [^] # Re: Conseils ?

        Posté par  . Évalué à 3.

        j'ai mis /usr et /usr/local en ext2, mais en ro seulement !
        comme ca, meme en cas de plantage, pas de pb puisque le fs est en ro.


        Dans le temps où seul ext2 existait, j'avais aussi fait comme toi (montage en RO) pour éviter un fsck long et inutile, sur une partition où j'écrivais très peu (inutile dans le sens où le FS n'avait pas été démonté proprement, mais que la structure était intègre, vu qu'aucune écriture n'était en cours au moment de la coupure).

        Cela dit, tant que tu n'écris pas sur tes partitions /usr et /usr/local, tu ne peux pas les corrompre, autant les laisser en RW (et ext3). Ca t'évitera de faire les remount et surtout d'y penser. En ext3 les performances en lectures sont les mêmes qu'en ext2, si je ne m'abuse. Maintenant qu'on a ext3 et qu'on évite un long et inutile fsck, je laisse mes partitions /usr et /opt en RW.
  • # Incohèrences de versions

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

    A notter pour ceux qui voudraient essayer, on q (à l'heure actuelle) sur le serveur de téléchargement (http://thebsh.namesys.com/snapshots/(...)) un fichier " LATEST_IS_2004.08.13", et pourtant un lien "LATEST" qui pointe vers "2004.08.24" lequel ne contient pas les patchs du noyeau.
    Je suppose qu'ils ont voulu limiter la redondance du patch, mais c'est mal fait.

    Aussi, le patch est prévu pour un 2.6.4 mais ne semble pas s'appliquer trop mal sur les kernels récents (seulement quelques REJECT pour 2.8.1, et faciles à corriger).
    • [^] # Re: Incohèrences de versions

      Posté par  . Évalué à 2.

      Sinon il est inclu dans les derniers mm (à partir de 2.6.8.1-mm3) et si on veut juste les patches de reiser4, ils sont dans le broken-out.
  • # Innovations...

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

    Reiser4 est aussi différent de Reiserfs que Reiserfs l'était de ext2. La description http://namesys.com/v4/v4.html(...) est bluffante.

    La structure de reiser4 a une certaine parenté avec celle d'une base de données et la place occupée par les tout petits fichiers est optimisée.
    Ainsi le courrier stocké sous forme de mail-dir est beaucoup mieux géré par reiser4 que par ext2.

    Cette version majeure est donc sortie avec un an de retard sur la date initialement prévue et c'est très bien ainsi. En effet, nous avons déjà de bons systèmes de fichiers, fiables et opérationnels. Il n'y avait donc aucune urgence. Nous ne sommes plus à lépoque de Rémi Card créant ext2.
    Nul doute que le code a été soigneusement testé et debuggé pendant cette année. Reiser4 ne peut s'imposer que s'il est meilleur que les autres FS et d'une fiabilité au moins aussi bonne. C'est à dire que la barre est placée très haut et que Hans Reiser n'a pas le droit de se planter.
    Comme la perfection n'est pas de ce monde, Hans est obligé de prendre quelques précautions quant à la stabilité car reiser4 n'a pas encore été testé sur plusieurs millions de machines. Il y aura bien quelqu'un qui trouvera un problème après avoir redimensionné à chaud une partition LVM sur du raid logiciel utilisant un disque SATA et un Firewire IEEE1394.

    En résumé, je pense que l'on peut utiliser en confiance reiser4 chez soi. Si c'est pour équiper une machine critique, ce n'est pas forcément un choix très judicieux.
    • [^] # Re: Innovations...

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

      Les "supporters"/"fans" de ReiserFS semblent avoir choisi ce FS pour les côtés originaux de la bête par "opposition" à la fiabilité/robustesse/ancienneté des ext2/ext3 (sorte de préférence, un truc subjectif, quoi, chacun ayant son mot à dire). Il ne leur reste qu'à utiliser et éprouver ReiserFS partout où ça leur est possible/utile, et ainsi de le mettre à l'épreuve pour justement que ce système de fichier gagne en robustesse au fil des rapports de bugs, benchmarks et autres petits problèmes qu'on rencontre tous les jours.

      Celà dit, il est vrai que les côtés innovants voire "révolutionnaires" de ReiserFS font quand même la fierté d'une partie de la communauté Libre/OpenSource...

      [/sérieux>

      Tout de même Pierre, je trouve pas très ambitieux : RAID + LVM est un grand classique gagnant du monde GNU/Linux, même si c'est sur du SATA+Firewire... Ne préfèrerais-tu pas essayer ReiserFS4 sur un ENBD sur du RAID 0+1 avec une couche EVMS par dessus, le tout dans un InterMezzo, Coda, ou OpenAFS ? Ce serait bien plus innovant !... Une bière à celui qui mets ça en place chez lui. Une bouffe, s'il nous fait un retour d'expérience concis rédigé dans son journal ! ;-)
      http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html(...)
      http://tldp.org/HOWTO/LVM-HOWTO/(...)
      http://freshmeat.net/projects/enbd/(...)
      http://freshmeat.net/projects/evms/(...)
      • [^] # Re: Innovations...

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

        Celà dit, il est vrai que les côtés innovants voire "révolutionnaires" de ReiserFS font quand même la fierté d'une partie de la communauté Libre/OpenSource...

        J'ai même l'impression que reiser4 est une étape importante. Les FS : XFS, JFS et NTFS sont maintenant dépassés par une solution libre. J'ai même l'impression qu'aucune concurrence ne viendra plus lui contester sa suprématie. En effet JFS et XFS qui sont maintenant OpenSource (ou mieux, je n'ai pas vérifié) ne seront certainement plus développés si une solution performante et fiable est disponible. Economiquement, IBM n'a aucun intérêt à investir dans un super JFS et SGI encore moins pour XFS.
        L'inconnue est pour Microsoft qui a les moyens financiers de développper un nouveau FS. Mais comme l'adoption d'un FS moderne n'a pas été une priorité (il a fallu attendre XP), il est peu probable qu'un inestissement peu rentable soit fait puisque NTFS fonctionne.

        PS : Pour le challenge, je double la mise ;-) lol !
        • [^] # Re: Innovations...

          Posté par  . Évalué à 8.

          J'ai même l'impression que reiser4 est une étape importante. Les FS : XFS, JFS et NTFS sont maintenant dépassés par une solution libre. J'ai même l'impression qu'aucune concurrence ne viendra plus lui contester sa suprématie.

          Depasses en quoi ?

          Les plugin ? Deja dans NTFS depuis des lustres
          Optimisation pour petits fichiers ? Deja dans NTFS depuis longtemps(ils vont dans la MFT, n'utilisent pas de clusters)
          ...

          Et je serais pas surpris du tout que XFS ou JFS soient dans le meme panier.

          Je crois surtout que tu t'es laisse impressioner par une page pleine de mots techniques et un manque de connaissance des autres FS

          Et il y a une autre chose qu'il ne faut pas oublier, c'est que les features d'un filesystem sont totalement inutiles si rien dans les couches du dessus ne les utilise, il faudra du temps pour voir si les couches hautes de Linux se mettent a supporter les extensions de ReiserFS
          • [^] # Re: Innovations...

            Posté par  . Évalué à 3.

            Pour ce qui du NTFS j'aimerais savoir un truc : pourquoi est-ce qu'il se fragmente autant ? J'ai une petite partition Windows XP dédiée uniquement au système l'utilisant et en moins d'une semaine d'utilisation je me retrouve avec taux de fragmentation monstre.
        • [^] # Re: Innovations...

          Posté par  . Évalué à 2.

          > aucune concurrence ne viendra plus lui contester sa suprématie.

          Dans le domaine des FS, rien est gagné d'avance et rien ne se gagne sur le papier pour Linux tant il y a de concurrence.

          Les éloges pleuvaient pour reiserfs (v3) et ext3 était considéré par certains comme un projet mort-né. En effet, ext3 est sorti après reiserfs (c-à-d qu'il est venu contester la suprématie de reiserfs :-)).
          On connait la suite de l'histoire jusqu'à Linux 2.6.9-rc1 (au jour d'aujourd'hui).

          Si on regarde encore en arrière, il y a ext2. Tout le monde disait qu'avec ext2, ext avait poussé son dernier souffre. Pourtant il y a eu ext3. Il y aura peut-être ext4, les autres bossent aussi, etc.

          Maintenant, un FS n'est pas seulement le format de stockage/organisation des données sur le disque dure pour y accéder rapidement. Il faut un haut niveau de fiabilité, supporter acl et selinux, ne pas avoir de problème de monté en charge, bien fonctionner avec lvm, etc.

          On voit aussi la montée en puissance des clusters pour les systèmes de fichier.
          Faut pas oublier qu'il n'y a pas que les FS avec plein de fichiers pour stocker des données. Il y a aussi les bases données et c'est plus efficace et plus souple lorsque les données sont bien organisées.

          Reiserfs est peut-être le FS ultime aujourd'hui (quoiqu'il reste encore beaucoup de boulot apparament) mais pour demain, personne ne sait.

          > Pour le challenge, je double la mise ;-)

          T'avais pas déjà perdu ta chemise avec reiserfs v3 ?
          • [^] # Re: Innovations...

            Posté par  . Évalué à 1.

            La suite...

            En dépillant mon courrier de la mailing devel de Fedora, je suis tombé sur une discution sur reiserfs4 (forcément).

            Et il y a eu le "pourquoi pas de reiserfs dans FC3 actuellement ?".

            De: Russell Coker
            Sujet: Re: reiser4
            Date: Thu, 26 Aug 2004 00:29:18 +1000
              SE Linux is a core feature of Fedora, and will be enabled by default in RHEL4.

              Reiser 3 does not work with SE Linux and probably never will.

              Reiser 4 has not yet been tested with SE Linux (AFAIK). I would not be surprised if testing revealed the same issues that we had with Reiser 3.

              These issues are a reason for us to recommend against ReiserFS. We can only recommend and fully support features that work with all the major features of the distribution. If Reiser 4 can work well with SE Linux and get included in the kernel.org kernels then it can be supported as soon as we use one of the kernel.org kernels with ReiserFS included (which may be a while, we could be on 2.6.8 for a while).

            De: Toshio
            Sujet: reiserfs v3 and SELinux (Was Re: reiser4)
            Date: Wed, 25 Aug 2004 11:02:05 -0400
              What are the problems with Reiserfs 3? I thought the patches from Chris Mason of SuSE that went into the mainstream kernel in 2.6.7 enabled SELinux.

            De: Stephen Smalley
            Sujet: Re: reiserfs v3 and SELinux (Was Re: reiser4)
            Date: Wed, 25 Aug 2004 11:13:59 -0400
              Deadlock in the reiserfs xattr code when creating the internal directories and files used to store xattrs (when interacting with SELinux) and lack of a mechanism for informing SELinux that it shouldn't mediate access to the internal directories and files used by reiserfs to store its xattrs.

            Parfois il suffit de pas grand chose pour rendre un FS inutilisable... Pour reiserfs v3 la solution n'est pas encore là. Pour que reiser4 soit en production, ça va être long.

            Pas facile la vie de système de fichier :-)
    • [^] # Re: Innovations...

      Posté par  . Évalué à 1.

      > Nous ne sommes plus à lépoque de Rémi Card créant ext2.

      ext2 n'a pas été fait dans l'urgence. Avant il y avait ext et encore avant minix.

      Tiens, j'y pense. Pourquoi les gens pour critiquer ext3 de fs pas moderne font référence à ext2 alors qu'il pourrait faire référence à ext qui est encore plus vieu :-)
  • # Convertibilité

    Posté par  . Évalué à 2.

    Je vais sans doute poser une question à la con, mais est-il (ou sera-t-il) possible de convertir une partition ReiserFS en partition Reiser4, sans perte de fichier évidemment ?

    [semi-troll]
    Je n'ai pas vu cette fonctionnalité sur la page de Reiser4, donc j'imagine qu'elle est inexistante.
    Mais je ne pense pas qu'une telle opération soit impossible, car Microsoft fournissait systématiquement un outil pour convertir les systèmes de fichiers de ses partitions en la version la plus récente (FAT16 -> FAT32 pour Windows 98 (ou ME), FAT32 -> NTFS pour Windows XP).
    [/semi-troll]
    • [^] # Re: Convertibilité

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

      La réponse est dans le FAQ :

      Will it be possible to read/write ReiserFS partitions created now with future versions of ReiserFS?
      Yes. ReiserFS-3.6.x (Linux-2.4.x) works with both the old (3.5) and the new (3.6) formats. ReiserFS-3.5.x (Linux-2.2.x) can only work with the old (3.5) disk-format. There is no way to convert the new (3.6) disk-format to the old (3.5), but the old (3.5) format could be converted to the new one (3.6) with the "-o conv" mount option.

      To upgrade from reiserfs V3 to V4, use tar, or sponsor us to write a convertfs.

      http://slashdot.org/comments.pl?sid=72530&cid=6540673(...)
    • [^] # Re: Convertibilité

      Posté par  . Évalué à 6.

      > Je vais sans doute poser une question à la con

      Nan, c'est une bonne question :)

      > mais est-il (ou sera-t-il) possible de convertir une partition
      > ReiserFS en partition Reiser4

      Non (en fait, ces 2 FS n'ont vraiment rien en commun, et la conversion n'aurait rien de plus naturel que vers/depuis n'importe quel autre FS). Il faudra passer par un bon vieux tar.
      • [^] # Re: Convertibilité

        Posté par  . Évalué à 1.

        woualah, un doublon avec 22 minutes de retard... Je râme avec mes tabs moi...
      • [^] # Re: Convertibilité

        Posté par  . Évalué à 1.

        en fait, ces 2 FS n'ont vraiment rien en commun
        Et ?
        Regarde l'exemple donné avant : Microsoft fournissait systématiquement un outil pour convertir les systèmes de fichiers de ses partitions en la version la plus récente (FAT16 -> FAT32 pour Windows 98 (ou ME), FAT32 -> NTFS pour Windows XP)
        FAT 16 et FAT 32 sont très proches, c'est sur. Par contre, FAT32 et NTFS n'ont rien en commun. Enfin, je suis sur pour NTFS4 d'XP, pour NTFS3 de NT4 je sais pas je le connais pas...
        • [^] # Re: Convertibilité

          Posté par  . Évalué à 3.

          J'ai pas dit qu'il était impossible de faire un prog de conversion (d'ailleurs namesys propose de le faire si on les paye pour ça), j'ai juste dit que c'était pas parcequ'il y avait "reiser" dans les noms de ces deux FS qu'un prog de conversion serait plus naturel à faire que vers ou depuis n'importe quel autre FS. Je pense que si tu les payes pour faire un convertisseur depuis ext3, ça ne sera ni plus facile ni plus difficile, et qu'ils le feront tout aussi volontier. Il n'y a donc pas de raison de s'attendre plus à voir apparaitre un convertisseur reseir3->reseir4 que la même chose pour ext3->reiser4.
  • # Pous tester

    Posté par  . Évalué à 2.

    Yoper 2.1 est sorti avec support du Reiserfs 4 pour la partition racine.
    cf : http://www.yoper.com/(...)
    Je n'ai jamais testé yoper, je ne sais pas ce que ça vaut.
    • [^] # Re: Pous tester

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

      Tiens, j'etais jamais allé sur leur site mais yoper utilise des composants de YaST pour la conf systeme :) La preuve que ca a du bon la libération du projet :)

      http://www.yoper.com/ss2.html(...) => SAX2
      • [^] # Re: SAX 2

        Posté par  . Évalué à 3.

        SAX 2 a toujours été libre (GPL ou license XFRee, je sais plus...)
        voir les licenses sur ftp.suse.com ou les anciennes versions sont dispos

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

  • # Dancing tree ?

    Posté par  . Évalué à 10.

    Au menu également les "dancing trees"

    Reiser4 le filesystem idéal pour samba ?
  • # Problème

    Posté par  . Évalué à 10.

    Désolé de refroidir votre enthousiasme, mais il y a un problème avec ReiserFs...

    Lorsqu'on tente un open sur un fichier avec l'attribut O_DIRECTORY, l'ouverture réussit toujours, ce qui casse certaines applications utilisant la valeur de retour d'opendir pour certains tests. De plus, certains programmes utilisent directement cet attribut comme optimisation par rapport à l'appel de stat(), et ces applications aussi riquent d'être cassées.

    Du coup, je crains fort qu'il n'y ait des problèmes de compatibilité avec ReiserFs...

    Et ce n'est malheureusement pas le seul problème. Pour plus de détails : http://www.uwsg.indiana.edu/hypermail/linux/kernel/0408.3/0211.html(...)
  • # Récupération d'un fichier supprimé

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

    On sait qu'on peut actuellement avoir des chances récupérer un fichier effacé (par erreur) sur ext2 avec certains outils (par exemple recover). Rien de tel en revanche sur ext3

    Est-ce également le cas avec RaiserFS ?

    PS : Oui les backups c'est bien, mais il a toujours été difficile de récupérer un fichier binaire créé il y de cela quelques heures.
    • [^] # Re: Récupération d'un fichier supprimé

      Posté par  . Évalué à 2.

      il a toujours été difficile de récupérer un fichier binaire créé il y de cela quelques heures.

      Indépendamment du système de fichiers, tu peux toujours faire :


      cat /proc/kcore > /tmp/mon_fichier (en root),
      puis strings /tmp/mon_fichier | less


      Pour essayer de récupérer le source. Si tu n'avais pas le(s) fichier(s) source, c'est plus difficile, mais il faudra que tu m'expliques comment tu crées des binaires sans source :-) .
      • [^] # Re: Récupération d'un fichier supprimé

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

        oui less /proc/kcore est très bien pour récupérer des fichiers ascii pour autant bien sûr que la machine n'a pas été rebootée depuis la suppression.

        Comment créer un fichier binaire sans source ? Installes-toi devant gimp pendant une heure, je suis sûr que tu trouveras.
        • [^] # Re: Récupération d'un fichier supprimé

          Posté par  . Évalué à 5.

          Comment créer un fichier binaire sans source ? Installes-toi devant gimp pendant une heure, je suis sûr que tu trouveras.

          Un point pour toi :-) .

          Et si tu te créais un script du genre :


          #!/bin/sh
          for i in `find /home/coinkoin -name "*"` ; do
          [ ! -f /home/save/$i ] && ln /home/save/$i $i
          done


          Tu n'aurais qu'à appeler ce script dans la crontab du root (ou même la tienne), avec exécution toutes les minutes (ln, ça ne coûte rien).

          Comme ça, si tu effaces le fichier, et que tu changes d'avis, tu n'as qu'à le récupérer dans /home/save !

          Il te suffira alors de faire le ménage dans /home/save de temps en temps (par exemple en utilisant tmpwatch avec un paramètre de 15 jours dans la crontab du root, une fois par jour), et le tour est joué.

          Plutôt joli, ce truc, je devrais peut-être le poster comme une astuce sur DLFP. Qu'est-ce que tu en penses?
          • [^] # Re: Récupération d'un fichier supprimé

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

            Qu'est-ce que tu en penses?


            Oui pas mal, en plus ça gère les modifications. C'est une jolie astuce de backup minimal. Nécessite :

            - Beaucoup d'espace disque si il y a beaucoup de fichiers ou simplement de gros fichiers

            - d'appeler le cron très souvent

            Ma question première reste ouverte : est-ce que ReiserFS est capable de gérer un recover ?
            • [^] # Re: Récupération d'un fichier supprimé

              Posté par  . Évalué à 3.

              Beaucoup d'espace disque si il y a beaucoup de fichiers ou simplement de gros fichiers

              Hé non, justement! ln fait des liens matériels, donc il ne crée aucun fichier. Bon, il faut quand même de l'espace disque conséquent si on supprime beaucoup de gros fichiers, ou bien énormément de fichiers quelconques, mais sinon, pas besois d'un espace disque particulièrement élevé.
              • [^] # Re: Récupération d'un fichier supprimé

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

                Hmmm, ok faudra que je teste y compris entre deux partitions différentes car j'ai quelques doutes....
                • [^] # Re: Récupération d'un fichier supprimé

                  Posté par  . Évalué à 3.

                  Les liens physiques ne marchent pas entre deux périphériques (ou partitions) différents.
                  
                  
                  
                  C'est pour celà qu'il y a les liens symboliques :-)
                  
                  man ln :
                  
                  
                  DESCRIPTION
                         Sous Unix, il existe deux types de ‘liens’  entre  fichiers,  que  l’on
                         nomme  généralement liens matériels (ou physiques) et liens symboliques
                         (ou logiques).
                   
                         Un lien matériel est simplement une manière de nommer  un  fichier.  Un
                         fichier  peut  avoir plusieurs noms. Un fichier n’est effacé réellement
                         que lorsque son dernier nom  est  supprimé.  Le  nombre  de  noms  d’un
                         fichier  est  indiqué par la commande ls(1).  Il n’y a pas de notion de
                         nom ‘original’ : tous les noms d’un  fichier  ont  exactement  la  même
                         importance.  Tous les noms d’un fichier se trouvent généralement - mais
                         ce n’est pas obligatoire - dans le système de  fichiers  contenant  les
                         données du fichier.
                   
                         Un  lien  symbolique  est  d’un  tout autre genre. Il s’agit d’un petit
                         fichier spécial, qui contient un chemin d’accès. Ainsi un lien  symbol-
                         ique  peut  pointer  vers  un système de fichier différent de celui qui
                         l’accueille.  Il peut également pointer, grâce à NFS, vers  un  système
                         de  fichiers appartenant à une autre machine. Enfin, un lien symbolique
                         ne pointe pas nécessairement vers un fichier  existant.
                  • [^] # Re: Récupération d'un fichier supprimé

                    Posté par  . Évalué à 4.

                    Les liens physiques ne marchent pas entre deux périphériques (ou partitions) différents

                    Tout-à-fait exact (encore que ce ne soit pas un comportement rigoureusement conforme POSIX ;-) ). C'est d'ailleurs pour ça que j'ai préconisé l'usage d'un compte /home/save, situé à priori lui aussi sur la partition /home.

                    Effectivement, si on partitionne /home entre les différents utilisateurs, ça ne marche plus, mais il s'agit à mon avis d'une manoeuvre rare, et dont je ne vois pas vraiment l'utilité.

                    Sauf s'il s'agit d'imposer des quotas de disque par utilisateur, mais dans ce cas, on peut toujours créer un répertoire ~/../save pour chaque utilisateur.

                    Je précise qu'il ne faut surtout pas remplacer ln par ln -s dans mon astuce, parce que le lien symbolique ne pointe justement pas les donnéees (si on efface le fichier cible, le lien symbolique pointera "en l'air" et les données seront perdues).
                    • [^] # Re: Récupération d'un fichier supprimé

                      Posté par  . Évalué à 3.

                      C'est une TRES TRES TRES mauvaise idée que de faire un « backup » sur la même partition. Le jour ou le fs est corrompu, ou que le disque tombe en panne, il ne reste plus rien et la sauvegarde n'aura servie à rien.

                      C'est du vécu :'(
                      • [^] # Re: Récupération d'un fichier supprimé

                        Posté par  . Évalué à 3.

                        C'est 2 types de backups complémentaires. L'un (celui avec des liens hard) peux être effectué à de très courts intervales de temps parcequ'il est peu coûteux. Il sert à prévenir les effacement involontaires par l'utilisateur, qui peuvent arriver assez souvent. L'autre (à coups de tar ou de rsync ou que sais-je), fait sur un autre média (autre dur, cdr, etc.), est plus coûteux et donc forcement moins synchrone (au mieux tu le fais toutes les 24H), mais par contre il est utile en cas de corruption du FS ou de crash disque hard.

                        Bref, deux problème, et deux solutions.
                  • [^] # Re: Récupération d'un fichier supprimé

                    Posté par  . Évalué à 4.

                    oui mais là tu perds ton fichier original si tu le supprimes, y-a pas de "recover" possible contrairement aux liens non-symboliques

                    PS : sinon le ln normal c'est bien pour le cas où tu supprimes un fichier par mégarde mais par contre ça n'empeche pas de sauvegarder régulièrement parce que si tu fusilles ton fichier de l'intérieur, c'est foutu
                • [^] # Re: Récupération d'un fichier supprimé

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

                  Les hardlinks entre deux partitions différentes ça marche pas non.

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

              • [^] # Re: Récupération d'un fichier supprimé

                Posté par  . Évalué à 5.

                Une question:
                Meme si tu supprimes ton fichier dans ton répertoire courant, tu supprimes pas reelement le fichier.
                Tu supprimes l'entree du fichier dans ton répertoire, mais l'inode du fichier existe encore et tu pointes dessus avec ton lien.
                Donc le fichier n'est pas détruit et cela la place qu'il occupe sur le fs n'est donc pas libérée.

                Je me dis que j'aurais du mieux suivre les cours sur le buffer cache et les inodes et les liens....

                So, j'ai dit une connerie ou pas?
                • [^] # Re: Récupération d'un fichier supprimé

                  Posté par  . Évalué à 7.

                  > So, j'ai dit une connerie ou pas?

                  Un petit exemple pour clarifier :
                  [me@here tmp]$ ll -h -i
                  total 2,6G
                  16134 -rw-r--r-- 1 me me 2,6G aoû 25 07:59 gros_fichier
                  [me@here tmp]$ df .
                  Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
                  /dev/md0 120111456 71511120 48600336 60% /
                  [me@here tmp]$ ln gros_fichier gros_fichier_ln1
                  [me@here tmp]$ ln gros_fichier gros_fichier_ln2
                  [me@here tmp]$ ln gros_fichier gros_fichier_ln3
                  [me@here tmp]$ ln gros_fichier gros_fichier_ln4
                  [me@here tmp]$ ln gros_fichier gros_fichier_ln5
                  [me@here tmp]$ ll -h -i
                  total 16G
                  16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier
                  16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln1
                  16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln2
                  16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln3
                  16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln4
                  16134 -rw-r--r-- 6 me me 2,6G aoû 25 07:59 gros_fichier_ln5
                  [me@here tmp]$ df .
                  Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
                  /dev/md0 120111456 71511120 48600336 60% /

                  Aucun espace disque de consommée en plus.

                  C'est toujours le même fichier (l'inode 16134) et le nombre de lien physique du inode/fichier est passé de 1 à 6. Le inode/fichier est supprimé lorsque le nombre de lien physique passe à 0.
                  D'ailleur il n'y a pas de commande (appel système) pour supprimer un fichier sous Unix !
                  Il y a unlink() qui supprime un lien physique. Si le nombre de lien physique passe à zero, le fichier est "enfin" supprimé.
                  • [^] # Re: Récupération d'un fichier supprimé

                    Posté par  . Évalué à 4.

                    Si le nombre de lien physique passe à zero, le fichier est "enfin" supprimé.

                    Et encore, uniquement quand le nombre de processus qui ont ouvert ce fichier tombe lui aussi à 0.
                    • [^] # Re: Récupération d'un fichier supprimé

                      Posté par  . Évalué à 10.

                      Bien vu.

                      Astuce :
                      Comme récupérer un fichier qui n'a plus de lien mais est encore ouvert par un processus ?
                      Simple, exemple :
                      $ cd /proc/359/fd
                      $ ll 6
                      lr-x------ 1 me me 64 aoû 25 16:22 6 -> /tmp/fichier (deleted)
                      $ cp 6 /tmp/fichier

                      Et voilà.
                  • [^] # Re: Récupération d'un fichier supprimé

                    Posté par  . Évalué à 2.

                    C'est ce qu'il me semblait, mais je m'exprime comme une bouse (pas avec les bons mots).
                    En tout cas, je pertinente tout le monde (dont toi).
                    Ce vocabulaire me rapelle l'universite, les bancs, toussa, la glande koi, ...
                    Snif!

                    Bref merci pour cette demonstration au poil!
            • [^] # Re: Récupération d'un fichier supprimé

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

              Comme système de backup original, il y a aussi qqun qui a fait un patch pour le noyau qui intercepte les suppressions de fichier et les déplace dans répertoire "trash". Je sais plus le nom de ce patch ni s'il est encore maintenu et j'arrive pas à le retrouver mais c'est déjà passé dans plusieurs journaux.

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

            • [^] # Re: Récupération d'un fichier supprimé

              Posté par  . Évalué à 2.

              Ma question première reste ouverte : est-ce que ReiserFS est capable de gérer un recover ?


              La réponse se trouve sur :

              http://linuxfr.org/tips/310.html(...)
          • [^] # Re: Récupération d'un fichier supprimé

            Posté par  . Évalué à 1.

            C'est marrant cette idée , ça me fait penser (de loin) aux snapshots sur les FS de Network Appliance.

            A quand cette fonctionnalité pour un FS sous Linux ?
        • [^] # Re: Récupération d'un fichier supprimé

          Posté par  . Évalué à 3.

          Installes-toi devant gimp pendant une heure, je suis sûr que tu trouveras.


          Tiens, effectivement, je n'avais pas pensé aux fichiers core ;-) .


          <Patapé!> - aïe, ouille, je ==>[] .
    • [^] # Re: Récupération d'un fichier supprimé

      Posté par  . Évalué à 5.

      Au fait, il y a une solution efficace, assez sale, et peu connue, pour récupérer un fichier que l'on vient d'effacer, sur n'importe quel UNIX (Linux compris). Attention toutefois, ça ne marche que si vous réagissez dans la seconde même de l'erreur.

      Il s'agit d'arracher la prise de courant de la machine (sic).

      En effet, le kernel cache les données des fichiers (et du système de fichiers) en mémoire centrale, et, dans le cas d'une coupure de courant, il n'a pas le temps de répercuter les derniers changements sur le disque.

      Cela dit, c'est vraiment un truc d'extrême urgence. Mais il peut servir.
      • [^] # Re: Récupération d'un fichier supprimé

        Posté par  . Évalué à 2.

        > Il s'agit d'arracher la prise de courant de la machine

        Ou le bouton reset. Ça m'a déjà sauvé quelques heures de boulot.
        • [^] # Re: Récupération d'un fichier supprimé

          Posté par  . Évalué à 2.

          Non,non, il s'agit bien d'arracher la prise de courrant et non d'un reset.

          Ceci, depuis le kernel 2.6.4 qui fait la difference entre les 2... :-)))
          • [^] # Re: Récupération d'un fichier supprimé

            Posté par  . Évalué à 3.

            Si je ne m'abuse, c'est pas vraiment une question de version du noyau, mais plutôt une question de savoir si le bouton reset est géré par l'ACPI ou bien direct par le hard. Il ne me semble pas qu'en APM, ou encore en ACPI sans le module qui va bien, l'OS puisse savoir qu'il va se faire rebooter, si ?
          • [^] # Re: Récupération d'un fichier supprimé

            Posté par  . Évalué à 2.

            Je parle du bouton reset et pas de <ctrl><alt><sup> .
            Avec le bouton reset, le cpu est figé de suite (idem pour les périphériques pci, etc) et il n'y a pas vidage du cache.
            Par contre le cache des disques (au niveau des disques et pas de l'OS) est écrit.
            Mais c'est aussi comme ça en cas de coupure de courrant. Les disques ont un minimum d'autonomie pour assurer l'écriture (sauf les très mauvais disque).
  • # Voir le thread "silent semantic change with reiser4" sur lkml

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

    Pour résumer reiser4 introduit dans le fs la notion tout fichier est un répertoire (oui ds ce sens la), et ça crée pas mal de trous de sécu très grave. Donc reiser4 a été véto-isé par al viro, mainteneur du vfs, car trop crappy pour l'instant. Voir le thread sur la ml pour les "gory details".
    • [^] # Re: Voir le thread "silent semantic change with reiser4" sur lkml

      Posté par  . Évalué à 1.

      Bonjour,
      A-t-il on bon lien pour résumé le fils qui est énorme, pour ceux qui n'ont pas le temps de tout lire, et qui aimeraient savoir si linux va de l'avant où reste arcbouté sur ses acquis (lire le fs du "futur": ext2 avec un patch pour le rendre journalisé: ext3; ça me rappel la comptabilité 16bits de ...).

      Merci.

      Bubu.

      NB: svp mettre la réponse à la question ci-après, et m'envoyer directement à cette adresse ( nobody@dev.null ) les remarques consernant le fs du futur. Merci encore!

Suivre le flux des commentaires

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