Forum Linux.général Filesystem XFS 32bits remonté sous Linux 64bits

Posté par .
Tags : aucun
1
8
déc.
2009
Bonjour,
après une brève recherche, je ne trouve pas de réponse à cette question qui n'est pas très banale. Je parle ici du système de fichiers SGI XFS (et pas X Font Server). Je me permets donc d'exposer ma problématique ici.

Je m'explique : sur une RHEL 4.3 i686 Kernel 2.6.9-34.ELsmp (32 bits), xfs a été compilé/installé à l'époque avec la version courante. Or, XFS est un FS natif 64bits qui supporte jusqu'à 16 EO de capacité globale. Mais il a été compilé sur un environnement 32bits et donc la capacité passe de 16 EO à 16 TO théoriques. Dommage.

Mais mon problème n'est pas là. Je dois migrer l'ancienne configuration sur une RHEL 5.4 x86_64 sachant qu'il y a des données volumineuses (quelques TO) et copier ces données va prendre un temps fou sans parler d'autres risques (je vous rassure, il y a un double backup). Ce problème ne concerne pas le système (/) qui est en ext3.

Ma question est la suivante : si je débranche le stockage fait avec xfs 32bits (baie RAID Fibre Channel), que j'installe RHEL 5.4 x86_64 (le hard est OK) avec XFS x86_64 :
- est-ce que je peux remonter ensuite le stockage 32bits en l'état sur le nouvel OS full x86_64 ? Je suppose que oui (qui peut le plus peut le moins) mais l'avis d'un expert me rassurerait.
- puis-je revenir en arrière, c'est à dire (j'ai 2 serveurs identiques sur place) rebrancher mon stockage FC 32 sur un RHEL 4 i686 après l'avoir monté au moins 1 fois dans un environnement x86_64 ?
- mais enfin et surtout, existe-t-il un outil qui permette de convertir explicitement le filesystem xfs actuel 32bits en 64bits dans le nouvel environnement ? Ou peut-être que ça se fait tout seul ? Si oui, comment le contrôler ?

Les rpms concernés sont : acl, attr, dmapi, kmod-xfs, xfsprogs, xfsdump.

Pardon si je ne poste pas au bon endroit.
Merci d'avance pour vos éventuelles réponses.
  • # il dit qu'il voit pas le rapport

    Posté par . Évalué à 3.

    je ne connais pas XFS mais dans le cas des autres filesystemes, il s'agit simplement de drivers

    quand tu avais le driver 32bits, tu ne pouvais pas depasser 16TO, ok donc ton disque fait maxi 16TO

    maintenant tu as un driver 64bits, ta machine pourras gerer un disque de 16EO
    tu t'en fous ton disque ne fait que 16TO


    maintenant, je suis peut-etre totalement à coté de la plaque,et il y a peut-etre des subtilités dans XFS qui empecheraient cela
    • [^] # Re: il dit qu'il voit pas le rapport

      Posté par . Évalué à 2.

      Salut et merci pour ta réponse.

      Ma question porte surtout sur la structure existante du FS XFS en place : est-elle limitée de construction à 32bits (2^32) ou est-elle d'emblée prête à évoluer vers 64bits si, comme tu le dis, la limite est uniquement liée au driver XFS qui utilise l'espace adressable à disposition (2^64).

      Ca veut dire dans ce cas que je ne pourrai pas revenir en arrière en 32bits si je dépasse les 16 TO, ce qui n'est pas le cas pour le moment.

      J'ai bien compris ton propos ?
      • [^] # Re: il dit qu'il voit pas le rapport

        Posté par . Évalué à 2.

        oui c'est comme ca que je comprend le fonctionnement d'un driver
        • [^] # Re: il dit qu'il voit pas le rapport

          Posté par . Évalué à 3.

          oO euh juste pour info un programme s'executant sur un systeme 32 bits (au sens large) pourra faire des additions et autres calculs sur 64, 128, 256 bits ou tout ce que vous lui direz de faire, hein.
      • [^] # Re: il dit qu'il voit pas le rapport

        Posté par . Évalué à 1.

        Le fait que le FS soit 64bits n'a rien a voir avec le fait d'avoir un systeme 32bit ou 64bit, ca signifie simplement la taille que le FS sait gerer.

        NTFS par exemple est 64bit depuis sa naissance en 1992, et cela quel que soit le cpu utilise.

        Donc a mon avis tu n'auras aucun probleme de migration, suffit de mounter le FS et c'est tout, tu pourras le passer entre OS 32 et 64bit sans probleme

Suivre le flux des commentaires

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