Ext4 bientôt sur votre bureau

Posté par . Modéré par Florent Zara.
Tags : aucun
1
18
oct.
2006
Linux
Ext3 est un des systèmes de fichiers les plus populaire dans le noyau Linux. Mais il ne permet pas de gérer des partitions de l'ordre du téra-octet (NdM : maximum de 16Go à 2To pour un fichier et de 2 à 32To pour une partition). Il devient évident que dans ce siècle, cela devient problématique. C'est avec cette constatation en tête que les développeurs du noyaux Linux viennent de « libérer » la première mouture de test à échelle humaine de la version ext4.

Il faut dire que Andrew Morton, un développeur bien connu (pour son kernel -mm), a déjà ajouté le nouveau système de fichier expérimental depuis le 10 octobre 2006.

Les possibilités de ce nouveau système de fichiers sont le support pour un stockage de 1024 péta-octets par volume. Un péta-octet est égal à 250 (deux à la puissance cinquante) octets. Il ne faut pas se tracasser, il y a bien des établissements qui utilisent le péta-octet comme unité normale de stockage (un exemple est la machine à remonter le temps de l'archive internet...).

Ext4 intègre également des nouveautés contenues dans les nouveaux systèmes de fichiers tels que Reiser4, JFS, etc. C'est également un système de fichier journalisé, ce qui permet de récupérer des données « perdues » bien plus facilement. Dans la lignée des ext, ext4 est rétro-compatible avec ext3. Il est donc possible de monter une partition ext4 en tant que ext3, on ne perd que la puissance des nouvelles possibilités.

Le nouveau système de fichiers est dans le noyau 2.6.19rc1-mm1. Si tout fonctionne comme prévu, il est espéré que ext4 soit pleinement opérationnel d'ici 6 à 9 mois. Comme toujours, si vous souhaitez tester ce filesystem, il est recommandé de sauvegarder vos données au préalable.
  • # La journalisation n'a rien à voir avec la récupération de données perdue

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

    > C'est également un système de fichier journalisé, ce qui permet de récupérer des données « perdues » bien plus facilement.

    Un système de fichiers journalisé est tout au plus un système de fichiers qui autorise une vérification d'intégrité rapide après un arrêt innopiné. Cela n'a rien à voir avec la possibilité de récupérer des données perdues. Si un cluster est défectueux au milieu du disque dur, le fait que le système de fichiers soit journalisé ou non ne m'aidera pas à récupérer les données perdues sur ce cluster.
    • [^] # Re: La journalisation n'a rien à voir avec la récupération de données pe

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

      Dans ce cas, comment appelle-t-on la journalisation des transactions elles-mêmes, comme les redo logs d'Oracle ?
      • [^] # Re: La journalisation n'a rien à voir avec la récupération de données pe

        Posté par . Évalué à 3.

        La journalisation que j'ai appris pendant mes études consistait à stocker de manière incrémentale les modifications du fs, pour pouvoir revenir dans un état précédent cohérent au besoin.

        Peut-être que les ext3 et autres mettent ça en oeuvre mais c'est en tout cas très minimaliste, il ne sait défaire que la dernière transaction ratée si j'ai bien compris. Au final ça ne garantit pas de pouvoir retrouver l'état du disque 10 minutes plus tôt en cas de crach.

        Ca serait cool un fs qui garde toutes les modifs depuis le boot précédent.
        • [^] # Re: La journalisation n'a rien à voir avec la récupération de données pe

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

          Au bout de deux ans d'uptime sur un serveur, je ne veux pas imaginé la taille du journal ....
          • [^] # Re: La journalisation n'a rien à voir avec la récupération de données pe

            Posté par . Évalué à 1.

            d'un autre coté, rien ne t'oblige à mettre /tmp et /var sous ce système de fichier...

            parce qu'après tout, c'est ce qui bouge le plus (outre la swap)


            bon, c'est vrai que ca perd directement de l'intérêt :D
          • [^] # Re: La journalisation n'a rien à voir avec la récupération de données pe

            Posté par . Évalué à -3.

            Je trouve que c'est un gros manque dans les FS habituels.

            Les utilisateurs qui ont l'habitude de patcher leur noyau, d'utiliser des drivers graphiques buggy... seraient bien contents de pouvoir ne pas perdre des données après un crash.

            Cela arrive quand même très souvent avec les FS qui se disent journalisés actuels, en particulier perdre ses préférences sous Gnome...
            • [^] # Re: La journalisation n'a rien à voir avec la récupération de données pe

              Posté par . Évalué à 2.

              > Cela arrive quand même très souvent avec les FS qui se disent journalisés actuels,

              Ils journalisent quoi ?

              Ext3 :
              Data Mode
              ---------
              There are 3 different data modes:

              * writeback mode
              In data=writeback mode, ext3 does not journal data at all. This mode provides
              a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
              mode - metadata journaling. A crash+recovery can cause incorrect data to
              appear in files which were written shortly before the crash. This mode will
              typically provide the best ext3 performance.

              * ordered mode
              In data=ordered mode, ext3 only officially journals metadata, but it logically
              groups metadata and data blocks into a single unit called a transaction. When
              it's time to write the new metadata out to disk, the associated data blocks
              are written first. In general, this mode performs slightly slower than
              writeback but significantly faster than journal mode.

              * journal mode
              data=journal mode provides full data and metadata journaling. All new data is
              written to the journal first, and then to its final location.
              In the event of a crash, the journal can be replayed, bringing both data and
              metadata into a consistent state. This mode is the slowest except when data
              needs to be read from and written to disk at the same time where it
              outperforms all others modes.


              La majorité des fs journalisé font "data=writeback".
              Par défaut ext3 fait "data=ordered".

              > Les utilisateurs qui ont l'habitude de patcher leur noyau, d'utiliser des drivers graphiques buggy...

              Pour ça il n'y a que les backups.
  • # Déjà dans la branche stable

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

    Le nouveau système de fichiers est dans le noyau 2.6.19rc1-mm1


    En fait, c'est plus que ça, le système de fichier Ext4 est déjà dans le 2.6.19-rc2-git-patatère.

    Autrement dit, le prochain noyau 2.6.19 proposera Ext4 (si l'option "experimental" est sélectionnée).
    • [^] # Re: Déjà dans la branche stable

      Posté par . Évalué à 8.

      > Autrement dit, le prochain noyau 2.6.19 proposera Ext4

      Rires :-)

      J'ai lu un peu la lkml est y a 1 semaine, deux patch pour ext4 et été soumis :
      1- une copie exacte de ext3 dans le répertoire ext4
      2- sed -e "s/ext3/ext4-devel/g"

      C'est tout pour l'instant :-)

      9 mois de boulot sont actuellement estimé pour avoir ext4. Patience.
      • [^] # Re: Déjà dans la branche stable

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

        J'ai lu un peu la lkml est y a 1 semaine, deux patch pour ext4 et été soumis :
        1- une copie exacte de ext3 dans le répertoire ext4
        2- sed -e "s/ext3/ext4-devel/g"

        C'est tout pour l'instant :-)


        Regarde les sources. [1]

        Moi j'ai regardé les sources du 2.6.19-rc2-g73ed9a86 (mais en fait le code d'Ext4 n'a pas changé depuis une semaine), et j'ai vu :

        Premièrement, il y a le support pour "extent" (voir http://www.linux-watch.com/news/NS3183866977.html ). Un petit fichier de 2 152 lignes, une paille.

        Deuxièment, il y a encore d'autres modifications dans le code qui n'ont rien à voir avec un simple changement de nom ou un nettoyage.

        Bien sûr que les 2 arbres sont très similaires, le fork vient juste de se produire. Mais c'est faux de dire que ce n'est qu'une copie de Ext3 avec un nom différent. D'ailleurs, je vois mal quel aurait été l'intérêt, dans ce cas, de faire ceci dans la branche stable.

        [1] Pour les fainéants : http://kernel.org/git/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Fl(...)
        • [^] # Re: Déjà dans la branche stable

          Posté par . Évalué à 6.

          > Mais c'est faux de dire que ce n'est qu'une copie de Ext3 avec un nom différent.

          C'était le cas quand j'ai regardé la lkml.
          http://marc.theaimsgroup.com/?l=git-commits-head&m=11605(...) Le 11/10/2006 ; donc il y a une semaine ; donc je n'ai pas dit de connerie.

          Les travaux viennent de débuté, je, on, tout le monde s'y attendait. Tu ne me surprends en rien. Oui les développeurs ont très probablement une belle pile de patch en attende...

          Par contre la news dit en titre "Ext4 bientôt sur votre bureau".
          La news dit aussi : Le nouveau système de fichiers est dans le noyau 2.6.19rc1-mm1.
          Là je trouve que c'est s'emballer bien fort !
          C'est une banche de développement qui vient juste de débuter.
          NB : Il me semble que le "il est espéré que ext4 soit pleinement opérationnel d'ici 6 à 9 mois" n'y était pas lorsque j'ai lu la news.

          En rien je ne voulais dénigrer ext[34]. J'utiliser quasi exclusivement ext2/3 depuis presque 9 ans !
          J'ai une quasi confiance absolue en ext3 (rock solid le bousin). Ces performances sont plus que respectables contrairement à ce qu'on lit ici et là (elles se sont significativement améliorées durant 2.6.x et le 2.6.18 apporte encore un petit coup de boost).
          J'ai aussi une grande confiance dans la façon dont sont menés les développements.

          > Mais c'est faux de dire que ce n'est qu'une copie de Ext3 avec un nom différent.

          C'était vrai le 10/11/2006. Il a été décidé de débuter avec une copie de ext3. A un moment la question c'est posé d'ajouter à ext3 (les sources) les fonctionnalité d'ext4. En effet, ext4 devra savoir utiliser le FS ext3 (donc ext3 (les sources) vont disparaite lorsqu'ext4 _final_ sortira). Mais ça a été jugé trop dangereux.

          > D'ailleurs, je vois mal quel aurait été l'intérêt, dans ce cas, de faire ceci dans la branche stable.

          T'as raté un épisode.
          Le dépôt de développement est/sera le linux 2.6 officiel. Donc oui, ça va exploser dans tout les sens au début et manger les jambes des enfants même si c'est fait dans une branche Linux dite stable.
          C'est pour ça que ext4 a été au début une copie de ext3. Il n'a pas été initialement ajouté ext4 (ou une version de développement) au noyau Linux mais seulement une copie de ext3.

          En fait, le développement a débuté mi-aout si j'ai bonne mémoire. Donc 2 mois seulement à "empiler" des patchs. Maintenant ils sont envoyés dans Linux (via Andrew) pour que tout le monde audite le code. Et le premier des patches est une copie d'ext3.
          • [^] # Re: Déjà dans la branche stable

            Posté par . Évalué à 1.

            > Oui les développeurs ont très probablement une belle pile de patch en attende...

            J'ai regardé, ils ont une belle pile de patch et beaucoup ont déjà été "bouffé" par la branche -mm.
            Je n'imaginait pas que ça puisse aller aussi vite :-)

            23 files changed, 5264 insertions(+), 2994 deletions(-)
  • # Et moi...

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

    ...en temps que particuliers avec mon Ubuntu, qu'est-ce que ca change ?
    C'est vrai on commence à trouver des disques 750Go

    Sinon, d'après le 1er lien, ext4 supportera l'option Extent : cela permet de reserver à l'avance une place contigue sur le disque, même si le fichier est plus petit. Lorsque que de nouvelles données seront écrites, elles le seront sur la place réservée, donc les accès seront plus rapide.

    D'après http://kerneltrap.org/node/7224 pour l'utiliser, il faut monter le FS avec une option particulière.
    • [^] # Re: Et moi...

      Posté par . Évalué à 5.

      Sinon, d'après le 1er lien, ext4 supportera l'option Extent : cela permet de reserver à l'avance une place contigue sur le disque, même si le fichier est plus petit. Lorsque que de nouvelles données seront écrites, elles le seront sur la place réservée, donc les accès seront plus rapide.

      Ce n'est pas la même chose que l'option de montage « reservation » pour l'ext3?
      • [^] # Re: Et moi...

        Posté par . Évalué à 2.

        > Ce n'est pas la même chose que l'option de montage « reservation » pour l'ext3?

        Non. Reservation est une technique qui ne touche pas le système de fichier écrit sur le disque. Reservation fait des réservations mais c'est uniquement tracé en mémoire vive. Par exemple tu écris 1ko sur un fichier, reservation va réserver de la place comme si tu écrivais par exemple 16ko. C'est-à-dire que ces 16ko sont réservés à ce fichier uniquement. Avantages : ça diminue la fragmentation du système de fichier, ça améliore la tenue en charge.

        C'est une description dans les grandes lignes !

        Le noyau 2.6.18 a un patch pour faire des lectures de donnée en avance (à ne pas confondre avec readahead des disques). Améliore la tenu en charge, diminue la consommation de cpu.
      • [^] # Re: Et moi...

        Posté par . Évalué à 1.

        > Ce n'est pas la même chose que l'option de montage « reservation » pour l'ext3?

        Je ne suis pas convaincu que l'option "reservation" soit nécessaire aujourd'hui. reservation doit être activé par défaut (la dernier fois que j'ai vérifié, c'était le cas).
  • # Performances ?

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

    Et au niveau des performances, qu'est-ce qui est annoncé ? A-t-on déjà quelques retours ?

    --
    http://www.tessier-net.org
  • # pardon ?

    Posté par . Évalué à 7.

    bon je suis peut être mal réveillé, mais où l'auteur a trouvé que ext3 ne gérait pas au dessus de 1Tera ?? J'ai ici des partoches de plus de 3Tera, alors si on parle de 1Tera = 1000Go, enfin bref un truc comme ça :
    /dev/sdd1 3,6T 2,3T 1,4T 63% /serveurs-backup
    ou encore comme ça :
    /dev/sdd1 on /serveurs-backup type ext3 (rw)
    bin je confirme, ça marche !
    • [^] # Re: pardon ?

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

      C'est clair, le système de fichiers ext3 peut supporter plus d'un tera-octets:

      D'après :
      http://fedoraproject.org/wiki/ext3-devel

      The current limits for ext2/ext3 filesystem are 2 terabytes with 1KB blocks, and 8 terabytes with 4KB blocks.
      • [^] # Re: pardon ?

        Posté par . Évalué à 2.

        Ça a un peu changé.
        FC6 a un patch pour supporter 2^32 bloques (il est aussi dans la banche -mm). Donc avec block size à 4 ko, ça fait 16 To. C'est principalement un passage de signed int à unsigned int.
        Des patchs ont circulé pour avoir block size de 8 ko voire 16 ko.
        Notons que ext3 ne peut faire mieux sur architecture 32 bits. C'est la limite du VFS quelque soit le FS.
    • [^] # Re: pardon ?

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

      2.3 To utilisé ?
      Ils sont gros tes backups ...
      • [^] # Re: pardon ?

        Posté par . Évalué à 4.

        bin je préfère dire que l'argent dépensé dans cette solution de sauvegarde est bien rentabilisé :-) en dessous ça aurait été gachis, et au dessus (enfin au dessus de 70%), ça m'aurait fait me sentir à l'étroit :-)
    • [^] # Re: pardon ?

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

      où l'auteur a trouvé que ext3 ne gérait pas au dessus de 1Tera ??

      D'après wikipedia[1][2], de 16Go à 2To pour un fichier et de 2 à 32To pour une partition.

      Pour ext4, wikipedia confirme[1][3] les 1024 Po annoncés dans la dépèche.

      Par ailleurs

      [1 ]http://en.wikipedia.org/wiki/Comparison_of_file_systems
      [2] http://en.wikipedia.org/wiki/Ext3
      [3] http://en.wikipedia.org/wiki/Ext4
  • # Ca pour une nouvelle ...

    Posté par . Évalué à 8.

    <mode="BeOS le faisait il y a dix ans">BeOS le faisait déjà il y a dix ans, avec les attributs étendus en prime !</mode>

    BeOS le faisait il y a 15 ans !

    • [^] # Re: Ca pour une nouvelle ...

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

      Les attributs étendus existent dans ext3, comme les ACL (stockés dans les attribus étendus), mais c'est super-chiant à sauvegarder et restorer...
      • [^] # Re: Ca pour une nouvelle ...

        Posté par . Évalué à -1.

        mais c'est super-chiant à sauvegarder et restorer...

        Même avec dar ?
      • [^] # Re: Ca pour une nouvelle ...

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

        star(1) (même interface que tar(1)) et pax(1) (POSIX) sont tes amis.

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

        • [^] # Re: Ca pour une nouvelle ...

          Posté par . Évalué à 1.

          Fedora a un patch pour ajouter le support des attributs étendus dans tar.
          rsync support les attributs étendus.
          Ça couvre aussi selinux.
  • # traduction

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

    C'est quoi ce délire de (mal) traduire des articles anglais et d'en faire des news sur DLFP ?

    (avant même d'aller voir l'article de linux watch, ça se voit grosse comme une maison cette traduction bancale à deux sous)
    • [^] # Re: traduction

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

      Moi j'aurais plutôt dit comme ça : "Merci d'avoir porposé la dépêche ! (même si la trad est pas top à certains endroits)"
      • [^] # Re: traduction

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

        Moi je ne dis pas merci a quelqu'un qui ne respecte pas les droits d'auteurs élémentaires.
        • [^] # Re: traduction

          Posté par . Évalué à 5.

          Hum hum...

          Désolé, mais j'ai commencer la trad correctement, puis, me suis dis qu'il n'y avais pas besoin de tout mettre...

          Juste un point pour les personnes qui n'avaient pas le temps/envie de traduire.

          Pour ce qui est des droits d'auteurs, j'ai mis le lien de linux watch... et j'avais commencer un texte (qui fut effacé par un admin je suppose).

          Alors, au lieu de tirer sur le pianiste, écoutez la musique.

          De toutes façons, c'est bien là une jolie manière de remercier le pianiste qui ne demandais que de jouer...
    • [^] # Re: traduction

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

      Effectivement, encore une fois, le respect des droits d'auteurs est bafoué. Sans autorisation de linux-watch et du rédacteur original, ce repompage est interdit.

      Sans compter la tromperie d'une traduction approximative sans citer explicitement que l'on a affaire a une traduction.
      Décidément, ya des mentalités que rien ne pourra changer :(
      • [^] # Re: traduction

        Posté par . Évalué à 9.

        Encore une fois, j'avais placé un texte au début...

        Oui, j'ai mis le lien de linux-watch... Mais j'aurais apparement pas dû.

        En tout cas, qu'on ne s'étonne pas que dlfp n'aie plus que des trolls pour vivre... pour ma part, c'est l'unique contribution qu'une bande de piaf de votre genre aura droit de ma part.

        Salutations
        • [^] # Re: traduction

          Posté par . Évalué à 10.

          Bonjour,
          je suis d'accord, l'accueil est un peu rude (j'y ai participé moi même, donc mea-culpa). Cependant, pour une news qui passe en "Une" de linuxfr, et qui va donc être beaucoup vue, je trouve "léger" de mettre des choses comme ext3 qui ne passe pas le tera, et la journalisation qui permet de récupérer des données.

          Maintenant pour moi la responsabilité (enfin c pas si grave hein !) est plutôt du côté de linuxfr : cette news n'aurait pas dû passer dans l'état en "Une". Donc, merci d'avoir présenté cette news, et dommage qu'elle soit passée sans être corrigée.
          • [^] # Re: traduction

            Posté par . Évalué à 1.

            Ben, c'est peut'être qu'ils on rien à mettre en une alors ils comblent avec ce qu'ils ont à porté de main ;o)
      • [^] # Re: traduction

        Posté par . Évalué à -4.

        bel adepte de masturbation intellectuelle que voilà... Enfin bref...
      • [^] # Re: traduction

        Posté par . Évalué à -4.

        encore une fois, ca se pignole comme des gros inactifs petits bourgeois, ca se tire dans les pattes, ca se tripote la nouille, ca gueule, mais ca pisse pas loin.

        allez zou.
  • # est pourquoi pas

    Posté par . Évalué à 1.

    utiliser ZFS (de SUN) ? ce FS semble très puissant. J'imagine que la question a déjà été posé...
  • # Compatibilité

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

    À propos de la compatibilité, j'aurais deux questions :

    1. Est-ce que la compatibilité ext3 va jusqu'à l'ext2 ? En d'autres mots, est-ce qu'il sera possible de monter un FS ext4 avec un noyau qui ne supporte que l'ext2 ? Je sais qu'il n'y en a plus beaucoup, mais je ne serais pas plus surpris que ça que certaines personnes soient un jour confrontées à la situation.

    2. Est-ce que je pourrai convertir mes partitions ext3 en ext4, comme j'avais converti mes vieilles partitions ext2 en ext3 avec une simple commande ? Ou bien une copie/sauvegarde sera-t-elle nécessaire ? Quand on voit que ce nouveau FS se destine aux stockages de grande capacité, tout copier peut prendre de nombreuses heures...
    • [^] # Re: Compatibilité

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

      Pour le 1/ , y a interet, dans la mesure ou si mes souvenirs sont bon, Grub ne sait gerer que l'ext2 (normal et logique en fait), ce serait balot d'avoir a creer un /boot ou carrement un / en ext2 ou ext3 a cause de ca...
      • [^] # Re: Compatibilité

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

        D'un autre côté, quel est l'intérêt d'un /boot en ext3 ou ext4?

        Je ne connais pas toutes les distributions, mais sous Gentoo en tout cas, le manuel d'installation préconise un /boot en ext2, ce dernier n'étant pas monté par défaut (noauto dans /etc/fstab) par le système.
        La journalisation et autres finesses d'ext3 ou ext4 (par rapport à ext2) ne sont-elles pas superflues pour ce type de partition/système de fichiers?
        • [^] # Re: Compatibilité

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

          Pas vraiment d'interet effectivement a faire un /boot en ext3 ou ext4, mais il faut aussi reconnaitre que depuis la disparition du probleme du boot au dela du 1024ieme cylindre, l'interet d'une partition /boot dediee s'est aussi quelque peu amoindrie... J'ai a l'esprit l'install par defaut de la Ubuntu qui ne cree qu'une partition / , et pas de /boot...
          • [^] # Re: Compatibilité

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

            Il est vrai que l'intéret de /boot sur une partoch à part semble faible aujourd'hui... Mais cela pourrait revenir...

            En effet pusique l'on parle ici de compatibilité, j'ai du mal à comprendre comment un module ext3 peut exploiter une partition ext4 si celle ci dépasse la taille limite de 32To... Le module fera t'il des coupes... et si l'envie lui prenait de couper /boot/vmlinuz*...

            La vrai question c'est comment est-il réellement possible d'assurer une compatibilitée dans ce sens si la partition dépasse la taille limite ext3. Il est hors de question d'avoir une gestion partielle (on garde que les inodes qui pointent sur des secteurs dans la zone des 32 To et on zappent les autres...) car un filesystem incohérent, c'est inadmissible.
          • [^] # Re: Compatibilité

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

            je suis toujours obligé de conserver une partition /boot à cause de LVM, en effet ni grub ni lilo ne savent comment aller y chercher le noyau. La flexibilité à un prix, celle d'une partition primaire :/
            • [^] # Re: Compatibilité

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

              Hummm, je regrette mais lilo est capable de lire sur du LVM. Et même si celui ci est sur du RAID logicielle.

              Preuve sur un de mes serveurs:

              monserveur:~$
              monserveur:~$df -Th
              Sys. de fich. Type Tail. Occ. Disp. %Occ. Monté sur
              /dev/mapper/volume0-rac
              reiserfs 5,0G 571M 4,5G 12% /
              tmpfs tmpfs 1015M 0 1015M 0% /dev/shm
              /dev/mapper/volume0-home
              reiserfs 30G 19G 12G 61% /home
              /dev/mapper/volume0-mnt
              reiserfs 60M 33M 28M 54% /mnt
              /dev/mapper/volume0-var
              reiserfs 30G 12G 19G 39% /var
              monserveur:~$pvdisplay
              --- Physical volume ---
              PV Name /dev/md0
              VG Name volume0
              PV Size 148,08 GB / not usable 0
              Allocatable yes
              PE Size (KByte) 4096
              Total PE 37909
              Free PE 21126
              Allocated PE 16783
              PV UUID hvOg9r-IsK3-INfj-6LvE-RKrr-LBjT-L6neqf

              monserveur:~$cat /proc/mdstat
              Personalities : [raid1]
              md0 : active raid1 hda1[0] hdc1[1]
              155276160 blocks [2/2] [UU]

              unused devices:
              monserveur:~$

              Comme tu peux le voir ici "/boot" est sur "/dev/mapper/volume0-rac" qui est une partoch du volume group "volume0" qui est composé seulement par le physical volume "/dev/md0". Ce dernier étant composé de "/dev/hda1" et "/dev/hdc1" en RAID1.

              Par contre pour installer cela j'ai fait une debian bootstrappée il y a longtemps tu dois surement faire cela de manière plus sympa aujourd'hui...

              Cordialement.
              • [^] # Re: Compatibilité

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

                Je confirme qu'au moins un boot loader fonctionne avec du raid.

                Dans mon cas il me semble que c'est le grub (plus sur à 100% mais 90%, c'est celui que je préfère), le serveur as été installé par la net install de debian il y as un an et depuis je n'y touche plus (serveur de données).

                Il y as un an on avait donc plus besoin de passer par du bootstrap pour installer un système raid ;)


                Cordialement,
                • [^] # Re: Compatibilité

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

                  J'ai dû louper quelque chose alors. Serait-il possible de connaitre les version de grub et de lilo que vous utilisez ?
                  • [^] # Re: Compatibilité

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

                    grub --version
                    grub (GNU GRUB 0.95) (debian SARGE)

                    ./TestHDD.sh
                    /dev/md0:
                    Version : 00.90.01
                    Creation Time : Wed Jun 1 16:44:44 2005
                    Raid Level : raid1
                    Array Size : 96256 (94.02 MiB 98.57 MB)
                    Device Size : 96256 (94.02 MiB 98.57 MB)
                    Raid Devices : 2
                    Total Devices : 2
                    Preferred Minor : 0
                    Persistence : Superblock is persistent

                    Update Time : Tue Oct 31 06:26:15 2006
                    State : clean
                    Active Devices : 2
                    Working Devices : 2
                    Failed Devices : 0
                    Spare Devices : 0

                    UUID : ad7be4b8:7ded47c3:92a0265e:a79fa7f2
                    Events : 0.2374

                    Number Major Minor RaidDevice State
                    0 8 1 0 active sync /dev/sda1
                    1 8 17 1 active sync /dev/sdb1
                    /dev/md1:
                    Version : 00.90.01
                    Creation Time : Wed Jun 1 16:44:50 2005
                    Raid Level : raid1
                    Array Size : 4883648 (4.66 GiB 5.00 GB)
                    Device Size : 4883648 (4.66 GiB 5.00 GB)
                    Raid Devices : 2
                    Total Devices : 2
                    Preferred Minor : 1
                    Persistence : Superblock is persistent

                    Update Time : Tue Oct 31 16:59:57 2006
                    State : clean
                    Active Devices : 2
                    Working Devices : 2
                    Failed Devices : 0
                    Spare Devices : 0

                    UUID : cae0db74:740c4b48:64ca4ba8:6d683c73
                    Events : 0.19169346

                    Number Major Minor RaidDevice State
                    0 8 2 0 active sync /dev/sda2
                    1 8 18 1 active sync /dev/sdb2
                    /dev/md2:
                    Version : 00.90.01
                    Creation Time : Wed Jun 1 16:45:01 2005
                    Raid Level : raid1
                    Array Size : 73240192 (69.85 GiB 75.00 GB)
                    Device Size : 73240192 (69.85 GiB 75.00 GB)
                    Raid Devices : 2
                    Total Devices : 2
                    Preferred Minor : 2
                    Persistence : Superblock is persistent

                    Update Time : Tue Oct 31 16:59:56 2006
                    State : clean
                    Active Devices : 2
                    Working Devices : 2
                    Failed Devices : 0
                    Spare Devices : 0

                    UUID : 0332a1b7:3842237d:5f9cc22a:273ff06e
                    Events : 0.12020739

                    Number Major Minor RaidDevice State
                    0 8 5 0 active sync /dev/sda5
                    1 8 21 1 active sync /dev/sdb5
                    /dev/md3:
                    Version : 00.90.01
                    Creation Time : Wed Jun 1 16:45:05 2005
                    Raid Level : raid0
                    Array Size : 2264960 (2.16 GiB 2.32 GB)
                    Raid Devices : 2
                    Total Devices : 2
                    Preferred Minor : 3
                    Persistence : Superblock is persistent

                    Update Time : Wed Jun 1 16:45:05 2005
                    State : clean
                    Active Devices : 2
                    Working Devices : 2
                    Failed Devices : 0
                    Spare Devices : 0

                    Chunk Size : 64K

                    UUID : e1067148:5833aa5d:88e4db8c:0fedba5d
                    Events : 0.1

                    Number Major Minor RaidDevice State
                    0 8 6 0 active sync /dev/sda6
                    1 8 22 1 active sync /dev/sdb6

                    df -h
                    Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
                    /dev/md1 4,6G 631M 3,8G 15% /
                    tmpfs 253M 4,0K 253M 1% /dev/shm
                    /dev/md0 89M 6,4M 77M 8% /boot
                    /dev/md3 2,2G 38M 2,2G 2% /tmp
                    /dev/md2 70G 55G 16G 78% /var

                    cat /etc/fstab
                    # /etc/fstab: static file system information.
                    #
                    # <file system> <mount point>
                    proc /proc proc defaults 0 0
                    /dev/md1 / ext3 defaults,errors=remount-ro 0 1
                    /dev/md0 /boot ext2 defaults 0 2
                    /dev/md3 /tmp reiserfs defaults 0 2
                    /dev/md2 /var reiserfs defaults 0 2
                    /dev/sda3 none swap sw 0 0
                    /dev/sdb3 none swap sw 0 0
                    /dev/hdb /media/cdrom0 iso9660 ro,user,noauto 0 0
                    #usb
                    /dev/sdc1 /mnt/usb vfat rw,user,users,noauto,umask=000 0 0
                  • [^] # Re: Compatibilité

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

                    Bien sur. Voici ma version de lilo:

                    monserver:~#lilo -V
                    LILO version 22.6.1 (Debian GNU/Linux)
                    monserver:~#


                    et ma config de lilo est:

                    #
                    boot=/dev/hda
                    #
                    root=/dev/mapper/volume0-rac
                    #
                    #
                    default=Linux
                    #
                    image=/vmlinuz
                    label=Linux
                    read-only
                    initrd=/initrd.img
                    #
                    image=/vmlinuz.old
                    label=LinuxOLD
                    read-only
                    optional
                    initrd=/initrd.img.old
  • # est pourquoi pas

    Posté par . Évalué à -7.

    utiliser ZFS (de SUN) ? ce FS semble très puissant. J'imagine que la question a déjà été posé...
    • [^] # Re: est pourquoi pas

      Posté par . Évalué à 10.

      J'imagine que la question a déjà été posé...

      Oui, par toi un peu plus haut :-)

      ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

Suivre le flux des commentaires

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