La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # j'ai rien à dire

    Posté par . Évalué à -10.

    vraiment rien...
    • [^] # MOI SI !!!!!!!!!!!!!

      Posté par . Évalué à -10.

      JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!

      JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!

      JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!

      JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!

      JE VOTE POUR LA POSSIBILITE DE DESACTIVER LA BOITE DES SONDAGES QUI NE ME SERT A RIEN ET QUI ME BOUFFE DE LA PLACE POUR RIEN !!!!

      Le comité pour la suppression de la boîte de sondage qui ne lui sert à rien et qui lui bouffe de la place pour rien.
  • # HFS

    Posté par . Évalué à -3.

    [*] HFS (ou HFS+ d'ailleurs. Au demeurant, je m'en balance, comme le bon aindeiouseur que je suis).

    Sinon, ils sont où les symboles /, \/ et X de cette boîte ?
    Je n'ai besoin que du "X".

    Merci.

    --
    On finira par y arriver...
    • [^] # Re: HFS

      Posté par . Évalué à 1.

      Je signe pour HFS+ également !
    • [^] # Re: HFS

      Posté par (page perso) . Évalué à 2.

      C'est vrai qu'il aurait été courtois d'inclure HFS+ dans la liste.
  • # et les *BSD ?

    Posté par . Évalué à 9.

    avec UFS et UFS2 ?

    À mince, c'est vrai, on est sur linuxfr.org
    • [^] # Re: et les *BSD ?

      Posté par . Évalué à 6.

      Mbah il y a bien NTFS, je vois pas pourquoi on oublierait UFS et meme HFS+ comme le remarquait un autre commentaire.
  • # Commentaire supprimé

    Posté par . Évalué à 5.

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

    • [^] # Re: ISO9660

      Posté par . Évalué à -1.

      Je n'ai ni Mac ni BSD, mais sous Windows en tout cas l'UDF passe très bien (même sous 98)
    • [^] # Re: ISO9660

      Posté par . Évalué à -1.

      Non, faut graver directement des fs EXT?/UFS/REISERFS !
    • [^] # Re: ISO9660

      Posté par . Évalué à -2.

      Je n'ai meme pas de lecteur de CD... Et je fais jamais de sauvegarde (Ooooohhh !) gniark gniark.
    • [^] # Re: ISO9660

      Posté par . Évalué à 6.

      Non car il s'agit d'une utilisation. Et a moins que tu n'utilise qu'exclusivement des live-cd ou tu ne grave 10 cd par jours, à chaque fois que tu te plante devant ton ordinateur tu utilise ta partition principal (au moins).
  • # pour moi

    Posté par (page perso) . Évalué à 2.

    Ext 3 pour linux, et FAT32 pour doze. (au moins pas de pb comme NTFS avec l'écriture depuis linux...)
    • [^] # Commentaire supprimé

      Posté par . Évalué à 4.

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

      • [^] # Re: pour moi

        Posté par (page perso) . Évalué à 2.

        sauf que captive-ntfs on attend toujours qu'il marche avec les noyaux 2.6.x, en attendant, merci PartitionMagic (NTFS->FAT32)
        • [^] # Re: pour moi

          Posté par . Évalué à 4.

          Muh ?
          J'utilise captive avec le noyau 2.6.7 et ça marche.........
          • [^] # Re: pour moi

            Posté par (page perso) . Évalué à 1.

            ?
            t'as du bol toi :) tu fais comment ?
            enfin trop tard perso j'ai tout passé en FAT32...
      • [^] # Re: pour moi

        Posté par . Évalué à 1.

        avec captive-ntfs il ne faut pas etre presser si l'on veut copier de gros fichiers sur sa partouche ntfs
  • # LVM powa

    Posté par . Évalué à 5.

    Moi c'est ReiserFS + LVM2
    C'est de la bombe (comme Sabrovitch) !
    Ho, une partition pleine, j'ai 5 GO non alloués dans le LVM : pouf, deux commandes et j'ai augmenté la taille de la partition sans la démonter !
    • [^] # Re: LVM powa

      Posté par (page perso) . Évalué à 2.

      Ah moi je reste en LVM1 pour quand je fais une connerie que je puisses recuperer sur ma knoppix :)
      maintenant que je reflechis avec le 2.6 de knoppix ptet que
      bon je regarderais ca :)
      en attendant
      reiserfs+lvm powa comme le dit ce cher PieD ;)
    • [^] # Re: LVM powa

      Posté par . Évalué à 0.

      Exact!
      LVM2 C de la bombe, au lieu de jetter mon ancien disque IDE, j'ai du LVM avec le Nouveau ! et au moins je peux faire autant de partoche que de répertoire!
      De plus on rajoute de l'espace disque en 2 commandes (par contre pour en retirer C pas facile..).
      Sous Mandrake, l'utilitaire d'installation permet de faire des manips de LVM facillement (voila un argument pour les install graphiques! ) .
      Enfin j'utilise du EXT3 car j'ai lu que ReiserFS et XFS étaient bons que sur des diques SCSI (cf: install de gentoo..).
      ----
      Fred
      • [^] # Re: LVM powa

        Posté par . Évalué à 1.

        Ben justement, si tu utilisais reiserfs, tu pourrais réduire des partitions facilement, et même sans les démonter ! C'est le seul.
        Ext3 peut y arriver mais la dernière fois où j'avais essayer, j'avais du démonter la partition, ça voulait pas.
        • [^] # Re: LVM powa

          Posté par (page perso) . Évalué à 1.

          reiserfs y a que l'agrandissement que tu peux faire a chaud
          pas la reduction
          mais bon au debut (en general du moins) tu prevois plutot trop petit que trop grand ;)
          • [^] # Re: LVM powa

            Posté par . Évalué à 5.

            Mais si, ça peut être réduit !
            Tu as un gros avertissement comme quoi c'est experimental, mais ça le fait !
            Je l'ai déjà fait plusieurs fois.
          • [^] # Re: LVM powa

            Posté par . Évalué à 1.

            Tu ne confondrais pas avec xfs par hasard ?
            • [^] # Re: LVM powa

              Posté par (page perso) . Évalué à 0.

              ben c cke me disait mon linux mag quoi :)
              et ce que me dis resize_reiserfs
              • [^] # Re: LVM powa

                Posté par . Évalué à 1.

                Le manuel de resize_reiserfs m'indique ceci :

                "
                The resize_reiserfs tool resizes an unmounted reiserfs file system. It
                enlarges or shrinks an reiserfs file system located on a device so that
                it will have size bytes or size=old_size +(-) size bytes if the + or -
                prefix is used. If the -s option is not specified, the filesystem will
                be resized to fill the given device. The size parameter may have one
                of the optional modifiers K, M, G, which means the size parameter is
                given in kilo-, mega-, gigabytes respectively.
                "


                Si il ne pouvait pas rétrécir un système de fichier de type Reiserfs, l'option '-' serait quelque peu inutile, selon moi.

                Par contre il me semble bien que le rétrécissement d'un système de fichier de type XFS est plus complexe...

                À confirmer
      • [^] # Re: LVM powa

        Posté par (page perso) . Évalué à 4.

        Je voudrais quand même émettre un petit avertissement.

        J'ai configuré ma Mandrake 10 Community Ed avec une première couche RAID façon logiciel, puis j'y ai rajouté une 2ème couche LVM2 pour enfin y installer mon ReiserFS.
        Bref une bonne petite configuration que l'outil Mandrake a pu me créer de manière facile. Mais il y a 2 hics :
        - impossible de booter sur cette configuration sans patcher les scripts init
        - l'outil graphique Mandrake ne sait pas relire la configuration énoncée plus haut

        En fait, au démarrage, Mandrake détecte d'abord s'il y a des partoches LVM et ensuite soft-RAID. Bref, avec ma configuration, une fois les partitions soft-RAID montées, il faut monter à la main le LVM pour ensuite avoir accès aux données! En touchant les scripts init ça résoud le problème (qq lignes à modifier pas plus) mais c'est chiant. J'ai d'ailleurs ouvert un bug chez Mandrake mais il ne semble toujours pas être pris en compte.

        PS: si ça intéresse quelqu'un mon patch, je pourrais l'envoyer sur ce site

        --
        Jean-Christophe
    • [^] # Re: LVM powa

      Posté par . Évalué à 3.

      Une fois j'ai eu un problème avec ReiserFS v3. Et l'outils fsck pour reiserfs v3 était vraiment pas d'une grande qualité (ce qui était même avoué par les auteurs), résultats perte de fichiers.

      D'un autre coté la version 4 est sensé être bien meilleure de ce point de vue là, et d'autres points de vue aussi :-D
    • [^] # Re: LVM powa

      Posté par (page perso) . Évalué à 0.

      Même si LVM est super interessant, je suis pas près de l'installer pour gérer plusieurs disques, parce que s'il y en a un qui lache...
      • [^] # Re: LVM powa

        Posté par . Évalué à 1.

        Mais tu peux toujours l'utiliser que sur un seul disque à la fois. Tu peux donc utliser un LVM pour chaque disque. Comme ça, si il y en a un qui lâche, bin tu est tranquille.
        • [^] # Re: LVM powa

          Posté par (page perso) . Évalué à 4.

          Sinon tu positionnes en dessous de ton LVM une couche RAID logicielle. Tu y perds un peu de place du fait de la redondance mais tu y gagnes en sécurité, tout en conservant la souplesse et les performances du LVM sur la couche supérieure. Donc si tu as un disque qui lâche, tu remplaces le disque défectueux et tu reconstruits ton RAID et tes données sont toujours là :-)
          A toi de voir si tu peux te permettre de te passer d'une partie de tes disques ou non...

          N.B.: j'ai fait le test en mettant 3 partitions de mon nouveau disque en RAID 5. J'ai ensuite flingué volontairement une partition avec fdisk. J'ai pu restaurer mon RAID avec une 4ème partition que j'avais laissée afin d'effectuer le test. Ca marche! j'ai rien perdu :-)) Mais bon, le disque n'était pas non plus bondé, j'y avais quelques fichiers seulement de gros volume que j'ai vérifié ensuite avec md5sum pour leur intégrité.

          --
          Jean-Christophe
    • [^] # Re: LVM powa

      Posté par (page perso) . Évalué à 2.

      À ce propos, l'un d'entre vous saurait-il si avec LVM et un seul disque dur si avoir un volume physique couvrant tout le disque ou plusieurs volumes physiques (avec des partitions plus petites) est à peu près équivalent ?
      J'ai besoin de migrer mes partitions classiques en LVM mais je ne peux pas le faire d'un coup (à cause de choses à sauvegarder).
  • # XFS

    Posté par . Évalué à -2.

    lo,

    l' XFS de Sgi est vraiment une bonne fs, je l'utilise sous Linux et Irix et je n' ai jamais eu de problemes avec ... l'ext3 est quand meme tres pratique surtt du cote de la recuperation des donnees (montage en ext2). en ce qui concerne reiferfs j attends la version 4 qui tarde a venir ...

    Pour les pros JFS c des cons ... car c'est vraiment une _ _ _ _ _ (cf perfs ...)

    IzuliuM
  • # et le NFS ?

    Posté par (page perso) . Évalué à 7.

    ben moi mon systeme est sous LTSP donc je suis obligatoirement sous NFS
    LTSP = Linux Terminal Server Project.


    boot en 1.30" arret immediat (power off) jamais de journalisation .....
    en plus on est 25 au bout du serveur.
    • [^] # Re: et le NFS ?

      Posté par (page perso) . Évalué à 2.

      Enfin avant d'arrêter ta station de travail, il faut quand même quitter tes applis...

      T'as bien testé, c'est rapide comme tout ?
    • [^] # Re: et le NFS ?

      Posté par (page perso) . Évalué à 7.

      boot en 1.30" arret immediat (power off) jamais de journalisation ..... en plus on est 25 au bout du serveur.


      Encore mieux : je bosse sur mon ibook -> je rabat l'écran (1 seconde pour se metter en veille) ; je le rouvre (1 seconde pour retrouver mon environement de travail tel que je l'ai laissé). Un reboot tous les 6 mois environ pour upgrader le noyau pour rester à la mode :o)

      Et après y en a qui disent que testing c'est pas stable ...

      En plus un ibook ca consomme rien (ca sauve la nature, les baleines, toussa) et ca fait pas de bruit et c'est bô.
      • [^] # Re: et le NFS ?

        Posté par (page perso) . Évalué à 1.

        Oui enfin un suspend-to-ram, en veille, ça consomme quand même et donc tu ne peux pas le laisser comme ça indéfiniment...

        Mon portable a 3 ans, je viens de me faire changer la carte mère et l'écran LCD juste avant la fin de garantie, j'espère bien qu'il va me faire 3 ans de plus. Quand ils ont changé l'écran j'ai cru que j'avais un nouveau portable, finalement sans s'en rendre compte les dalles perdent vraiment en contraste/lumière, surtout quand c'est resté allumé non-stop :)

        Moi perso je suis en ext3, le power off c'est `sync` et j'appuis sur le bouton.
      • [^] # Re: et le NFS ?

        Posté par . Évalué à 3.

        En plus un ibook ca consomme rien
        Et les centaines de litres d'eau qui ont été nécessaires à la fabrication de l'iBook ? Et les kilogrammes de produits chimiques hautement polluants ? Et les métaux lourds dans ton iBook ? Et le pétrole utilisé pour fabriquer le plastique ? C'est pas de la pollution ?
        (oui c'est pareil pour n'importe quel ordinateur, portable ou non, mais ça pollue quand même un max à fabriquer, tout ça...)
        • [^] # Re: et le NFS ?

          Posté par (page perso) . Évalué à 0.

          En même temps, dans le but de sauver la planète , tu ne consultes pas et tu ne postes pas sur linuxfr via pigeon voyageur !
          • [^] # Re: et le NFS ?

            Posté par . Évalué à -1.

            Ton idée est anti-monumenhistoricologiste
    • [^] # X remote display

      Posté par . Évalué à 1.

      Oui enfin précisons qu'une fois booté un terminal X utilises le système de fichier natif du serveur directement, sans passer par NFS. Il peut meme booter tout seul son OS sans NFS: avec son propre disque dur ou sur une disquette/CDrom/CF... (ce qui accélère les reboots massifs en cas de grosse panne... sinon le réseau est engorgé par tous les terminaux qui téléchargent en même temps leur OS par NFS)
      http://www.ltsp.org/(...)
      • [^] # Re: X remote display

        Posté par (page perso) . Évalué à 1.

        pour les applis c'est vrai faut quitter celle -ci, par contre pour le LTSP
        j'ais fait des modifs sur le systeme, mon serveur X est sur chaque terminal reduction de la bande passante + aucun probleme d'authentification . et puis un avantage indeniable par rapport a LTSP toutes les applications tourne sur les terminaux le serveur peut etre un banal PIII . par contre le réseau doit être top 1go pour le serveur sur un switch 1Go/100M.
        Je pense donner les modif prochainement en GPL .... wait and See
  • # manque le futur FS par défaut sous linux ;)

    Posté par . Évalué à 0.

    et reiser4? il pue?
    • [^] # Re: manque le futur FS par défaut sous linux ;)

      Posté par . Évalué à -1.

      Il plante...
    • [^] # Re: manque le futur FS par défaut sous linux ;)

      Posté par . Évalué à 0.

      La dernière fois que j'ai regardé il n'avait pas encore de fsck.
      Très génant.

      > manque le futur FS par défaut sous linux

      Mouaif...
      On a déjà lu 50 fois que ReiserFS v3 allait être le FS par défaut de Linux.
      Même ici (en France qui utilise moins RedHat/Fedora qui laisse peu de place à ReiserFS) il est 3 fois moins utilisé qu'ext3.
      • [^] # Re: manque le futur FS par défaut sous linux ;)

        Posté par . Évalué à 2.

        euh ben ca devait être y'a vraiment longtemps alors...

        reiserfs v3 n'a pas les memes performances et les memes fonctionnalités interressante qui font reiser4
        • [^] # Re: manque le futur FS par défaut sous linux ;)

          Posté par . Évalué à 1.

          > euh ben ca devait être y'a vraiment longtemps alors...

          Reiserfs est en upstream depuis Linux 2.4 (comme ext3). Donc c'est pas vieux.

          > les memes fonctionnalités interressante qui font reiser4

          reiser4 n'est toujours pas upstream et il manque fsck (ce qui est "grave"). Les attributs attendus ont été ajouté très récement (de façon élégante je trouve et peut-être que d'autres doivent s'en inspirer).

          Ce qui manque le plus à ext3 c'est le resize à chaud. Mais un patch existe et Red Hat bosse dessus plus ou moins. C'est présent dans FC2.

          Le temps que reiserfs v4 soit complètement débuggué et supporte toutes les "features" les plus classiques il faut encore attendre un bon moment.
          Lorsque quelqu'un demande pourquoi Red Hat n'"aime" pas reiserfs, Alan Cox, dont l'indépendance ne peut être mise en doute, répond que c'est car reiserfs ne passe pas les procédures de test Red Hat (en perfo et/ou fonctionnalité, j'ai oublié).

          A moins d'être obsédé par les performances, je n'utiliserais pas maintenant. Que ça ne vous empêche pas de l'utiliser au moins pour les tests et faire avancer cet innovant FS.
          • [^] # Re: manque le futur FS par défaut sous linux ;)

            Posté par . Évalué à 1.

            Perso j'ai jamais eu à me plaindre d'un reiserFS... Je l'utilise depuis la mandrake 9.2 et ce sur toutes mes partitions non win (pour quand j'en avais)
            • [^] # Re: manque le futur FS par défaut sous linux ;)

              Posté par . Évalué à 1.

              Si ça ne marche pas pour tous les tests tordus de Red Hat ça ne veut pas dire que ça ne marche pour tout le monde.
              Sûre que ça marche pour une très large majorité des utilisateurs.

              Si ça ne marche pas, ce n'est pas utilisé.
              Mais regardes, les statisques. C'est utilisé par beaucoup de monde et donc ça marcher pour beaucoup de monde.
          • [^] # Re: manque le futur FS par défaut sous linux ;)

            Posté par . Évalué à 1.

            > ... et il manque fsck (ce qui est "grave").

            Vraiment ?

            [root@strawberrythingy:~]# fsck.reiser4 --version
            fsck.reiser4 0.5.5
            Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by
            reiser4progs/COPYING.

            Bon, il faut dire que je n'ai pas encore eu à m'en servir donc je ne peux pas dire si il est efficace, mais en tout cas il est là.

            Sinon, je suis surtout reiserfs/xfs.
    • [^] # Re: manque le futur FS par défaut sous linux ;)

      Posté par (page perso) . Évalué à 0.

      Tu veux sans doute parler de ext4 ?
  • # swap n'est pas un système de fichier

    Posté par . Évalué à 5.

    certains vont me répondre que FAT n'y ressemble pas trop non plus mais bon ;)
  • # et le HPFS ???

    Posté par . Évalué à 1.

    ok ,pas d'OS/2 ici mais bon ...
  • # JFS

    Posté par . Évalué à 0.

    que penser vous de JFS ????

    a+
    Tof
    • [^] # Re: JFS

      Posté par (page perso) . Évalué à 1.

      c'est un SF très très robuste, mais par contre il a une défaut majeur!
      il bouffe trop de temps CPU dès qu'on lis ou écris(surtout) sur le disque...

      A n'utiliser que pour les données sensibles qui ne dopivent pas être perdue en cas de coupure de courant ou autre...

      Perso j'ai fait des reset et des freeze kernel et seul le JFS ne me faisait pas perdre de données, la où le ext3, ext2 et reiserFS pouvaient aller se réhabiller (perte de /usr, données sensibles, etc...) ...
      • [^] # Re: JFS

        Posté par . Évalué à 1.

        merci de ces quelques infos

        a+
        Tof
      • [^] # Re: JFS

        Posté par . Évalué à -1.

        > la où le ext3, ext2 et reiserFS pouvaient aller se réhabiller (perte de /usr

        Perte de /usr !?!?

        dans /usr il n'y a pas décriture normalement.
        J'avais des freezes aléatoires sur ma bécane (problème carte mère) et je n'ai jamais rien perdu avec ext3. J'ai de sérieux doute sur ce que tu avances...
        • [^] # Re: JFS

          Posté par (page perso) . Évalué à -1.

          mes pb venais de ma carte mère a l'époque, mais je puis te garantir que j'ai perdu mon /usr deux fois de suite avec de l'ext3 sous une mandrake 9.0.

          ça vienais peut-être de la mandrake, ou d'un bug dans le SF ou alors dans le program de gestion de l'ext3 en user mode (utilitaires ext3)
          • [^] # Re: JFS

            Posté par . Évalué à -1.

            > mes pb venais de ma carte mère a l'époque

            Avec des problèmes hard...
            J'ai aussi perdu des données avec ext3. Mais toujours pour des problèmes hard (disques vers la fin de vie).

            > ça vienais peut-être de la mandrake, ou d'un bug dans le SF ou alors dans le program de gestion de l'ext3 en user mode (utilitaires ext3)

            Ça venais peut-être aussi d'ext3 mais c'est rare. Un bug isolé peut toujours arrivé.

            Mais je vais te donner un petit exemple.
            À une époque il y avait un problème avec ext3. Ben en fait le problème n'était pas ext3 mais le drivers ntfs qui polluait la mémoire du noyau.

            Donc il faut y aller avec des pincettes avant d'affirmer :
            - "ext3, ext2 et reiserFS pouvaient aller se réhabiller"

            ext3 est un FS extrèmement utilisé/testé et reconnu pour sa fiabilité. S'il était "tout pourri" ça se serait.
      • [^] # Re: JFS

        Posté par . Évalué à 4.

        > la où le ext3, ext2 et reiserFS pouvaient aller se réhabiller (perte de /usr, données sensibles, etc...) ...

        Bon troll. Au moins pour ext3.
        Trouvé sur mailing Fedora. Un mec a fait plein de tests avec différents systèmes de fichier.
        http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034.(...)
        I finally managed to turn off the write caching on the SATA drives (see
        patch below) and I have re-run the tests on all four journaling file
        systems. And again I am completely stumped by the results.

        The test is really pretty simple. It is hooked to a machine that cycles
        the power. It runs for 5 minutes and then the power is turned off for
        1 minute (to simulate the plug being pulled). For this last set of tests
        it has 3 hard drives connected, one Parallel IDE and two Serial ATA. The
        system boots a minimal install of Fedora Core 2 from the IDE drive. No
        tests are running on the IDE drive. In the rc.local file it starts the
        fsstress test http://ltp.sf.net/nfs/fsstress.tgz(...) and the three scripts
        below (to simulate writing into a log file) on each of the SATA drives.

        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).

        I just can't understand what is happening, it makes no sense to me that
        one file system would be almost perfect and three would fail so
        dramatically. I am going to re-run the tests on all 4 file systems to
        verify that it is repeatable.

        Should I report these problems to the upstream projects (Reiser, XFS, JFS)?


        Réponse/éclaississement d'Alan Cox de ses petites pertes de donnée avec ext3 qui sont "normals" :
        [...]
        Unless you are doing data journalling or some kind of userspace
        transactions you wouldn't expect file contents to be perfect. Data
        journalling has a big performance cost.
        [...]
        Your expectations seem at odds with what journalling provides. A journalled
        fs can be recovered by log replay. It doesn't guarantee that user data is
        recovered precisely. It guarantees that user data is recovered to those
        points where it was committed.

        Thus
        open file O_APPEND
        write stuff
        close it

        repeat. doesn't guarantee "stuff" will always be committed - it just
        guarantees that the fs will be structurally sound

        open file O_APPEND
        write stuff
        fsync
        close

        OTOH says that after the fsync has returned you can be sure the data
        just wrote before it *will* still be there.

        Ext3 data journalling journals everything which is a bit slower but can
        be appropriate for some applications (and actually for big NFS servers
        often turns out to be faster because of the NFS commit behaviour)


        Réponse de Arjan van de Ven :
        this is expected behavior; by default ext3 has a journaling mode that is
        more safe than defaults of other filesystems, eg when you create a new
        file or extend an existing one, it will not commit the new size to disk
        before the data has been sent to the disk. Other journaling filesystems
        do this entirely asynchronous.
        The cost is raw performance, which is why ext3 has a mount option to
        emulate the behavior of the other journaling filesystems in both speed
        and, ehm, data security.

        Your investigation proves that we default to the right mode ;)


        Informations supplémentaires et utiles données par Bill Rugolsky Jr. :
        http://www.redhat.com/archives/fedora-test-list/2004-July/msg00036.(...)

        Il y a aussi eu un très long thread en avril :
        http://www.redhat.com/archives/fedora-test-list/2004-April/msg02646(...)

        Donc : il faut désactiver l'écriture en arrière plan du disque avant de faire des tests !
        Sinon ça ne marche pas et c'est un problème connu ! Sauf pour certains disques SCSI.
  • # et si on backup tout sur floppy ?

    Posté par . Évalué à -1.

    Vive le fat12 !!!!!

    le fat12 c l'avenir...

    n'empeche... c le format qui doit être le format le plus utilisé dans les administrations ;)

Suivre le flux des commentaires

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