Forum Linux.noyau disques mélangés au boot sur un Raid logiciel

Posté par  (site web personnel) .
Étiquettes : aucune
0
18
mar.
2011

Salut
j'ai un gros problème sur un ensemble Raid10 logiciel qui ne va plus depuis une mise à jour noyau.
Je me suis rendu compte, entre autres, que les disques sont mélangés au hasard lors du boot, et que cet ordre change à chaque boot. Par exemple je vais me retrouver avec (syslog): 

 sdc:
 sdd:
 sde:
 sdf: sda1 sda2
 sdg: sdc1
 sdd1
 sdg1
 sde1
 sdf1
et c'est souvent pire.

Au passage, sur ce même boot mdadm --examine me montre pour le disque sdd1

this     0       8       33        0      active sync   /dev/sdc1

   0     0       8       33        0      active sync   /dev/sdc1
   1     1       8       49        1      active sync   /dev/sdd1
   2     2       8       65        2      active sync   /dev/sde1
   3     3       8       81        3      active sync   /dev/sdf1
   4     4       8       97        4      spare   /dev/sdg1

Je ne comprend pas si ce mélange dans syslog n'est qu'apparent. Le problème de raid ne vient pas je pense de ça, mdadm utilise plutot les checksum pour repérer les disques.

  • # c'est pareil chez moi

    Posté par  . Évalué à 3.

    mais là je suis au bureau, et je ne me souviens plus comment j'ai truandé le systeme.

    De memoire pour moi ca ne change en fait pas grand chose, car je bootes sur le SSD via son UUID

    ensuite je monte le raid (mdadm raid10) mais il semble se debrouiller avec les disques qui changent de sdX/Y

    je regarderais quand meme chez moi (si j'oublie pas)

    • [^] # Re: c'est pareil chez moi

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

      Merci. Ça me rassure. J'essaie d'éliminer les causes du problème. Avec le stress engendré par un Raid en panne, c'est difficile de réfléchir clairement.

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

      • [^] # Re: c'est pareil chez moi

        Posté par  . Évalué à 2.

        Tiens ça me fait penser que j’ai eu une alerte récemment à ce propos en faisant une mise à jour. Tu serais pas sous Debian Testing par hasard ?

        • [^] # Re: c'est pareil chez moi

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

          Presque c'est une ubuntu server 10.04
          Le raid10 ne s'assemble plus depuis le passage au noyau 2.6.32-29
          Jusqu'ici je ne trouve d'aide ni d'explication quasiment nulle part. Je creuse...

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

          • [^] # Re: c'est pareil chez moi

            Posté par  . Évalué à 2.

            Ça doit pas être ça alors à priori, c’était une mise à jour du 2.6.37, et ils avertissaient que dorénavant nommer les périphérique via /dev/sd* n’était plus sûr et qu’il fallait passer par leur uuid.

          • [^] # Re: c'est pareil chez moi

            Posté par  . Évalué à 2.

            j'avais un souci similaire avec mon raid10, il m'a fallu rajouter un sleep dans un fichier pour qu'il s'active au demarrage (pour qu'il soit ensuite monter par fstab)

            je regardes ca car j'avais du le documenter pour ne pas me faire avoir la prochaine fois.
            voila, c'est ca :

            dans le fichier /usr/share/initramfs-tools/init
            rechercher les lignes (chez moi 236,237):

            maybe_break mount
            log_begin_msg "Mounting root file system"

            les modifier pour que cela devienne

            maybe_break mount
            sleep 10
            log_begin_msg "Mounting root file system"

            il faut ensuite regenerer le ramfs avec

            update-initramfs -u -k all

            ici c'est une ubuntu 10.10, mais j'avais le meme souci en 10.04

            • [^] # Re: c'est pareil chez moi

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

              Vu la sortie de mdadm --examine, j'ai l'impression que mon problème n'est pas de cet ordre.

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

              • [^] # Re: c'est pareil chez moi

                Posté par  . Évalué à 2.

                chez moi, avec un /dev/md0 actif, quand je fais mdadm --examine /dev/sdg (sdg etant un disque dans le raid, ca me donne

                Number Major Minor RaidDevice State

                this     2       8       96        2      active sync   /dev/sdg  
   0     0       8       16        0      active sync   /dev/sdb  
   1     1       8       32        1      active sync   /dev/sdc  
   2     2       8       96        2      active sync   /dev/sdg  
   3     3       8        0        3      active sync   /dev/sda

  • # identifier les paires de disques

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

    une autre question:
    comment indentifier les paires de disques dans un Raid 10 avec 4 disques?
    il est construit en Raid10 n2, ce qui devrait donner disk1 mirroir de disk 2 disk3 mirroir de disk 4

    alors que j'ai apparemment
    disk1 mirroir de disk4
    disk2 mirroir de disk3

    mon inquiétude vient du fait que mdadm --examine montre des disques mélangés:
    cf la sortie ci-dessus ou sdd1 est indiqué come étant en fait sdc1
    et pour les autres j'ai sde1 indiqué comme étant sdd1 sdd1 indiqué comme étant sdc1 sdc1 indiqué comme étant sde1

    du coup quand mdadm me propose de reconstruire, alors que j'ai enlevé 2 des 4 disques, je me demande si c'est fiable.
    une idée?

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

  • # nommage persistant des disques

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

    Je connais pas trop mdadm mais je suspecte que le problème est que tu utilises les devices sd comme devices sous-jacents à un md. Comme tu l'as remarqué, l'ordre de détection des devices peut changer et ce à quoi correspond chaque sd n'est donc pas constant. La solution est peut-être d'utiliser des noms persitants comme /dev/disk/by-uuid/ au lieu de /dev/sd*.

    Il y a ça qui peut aider à comprendre un peu l'affaire :
    http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html

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

Suivre le flux des commentaires

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