Raid 0 logiciel innaccessible, partition non montable

Support Debian
#1

Bonjour,

Je me permets de vous écrire aujourd’hui car je rencontre quelques soucis sur mon Raid 0 Jbod logiciel 2x2To

J’avais opté pour du jbod en me disant que si un des deux disques crève, je récupère les données au moins de l’autre.

Évidemment, ça fait 5 mois que ça tournais, j’ai pas fait de Backup, s’était sur ma liste de chose à faire

Voici le tuto que j’avais partiellement utilisé pour créer mon raid 0 :

https://linuxfr.org/wiki/tuto-howto-debian-ubuntu-creer-un-jbod-raid0-non-strip-avec-mdadm

Aujourd’hui, leur état de santé est bon d’après disks niveau smart, mais pas moyen d’accéder à la partition du raid.

Ce qui à changer c’est que j’ai sorti un nouveau SSD SATA pour installer Debian 11 sur mon serveur et pouvoir tout réinstaller sans rien perdre …

Je précise aussi, je sentais que mon ancien SSD était à la ramasse, j’en est changer pour ça, il est encore accessible, mais plus moyen de booter dessus, n’est plus détecté comme un volume bootable uefi.

  • Mon ancien SSD est en GPT UEFI
  • le nouveau je l’ai fait en MBR, j’ai plus confiance pour un boot en l’uefi lol

Sur mon nouveau Debian via l’utilitaire de disques (disks), je vois un de mes deux raids, mais celui qui m’intéresse n’est pas montable …

Je vous précise que mon niveau en linux n’est pas encore super bon, mais je veux m’améliorer, je suis motivé.

Je vous ai joint une capture d’écran de l’utilitaire disks et suis preneur de vos conseils pour rétablir la situation.

2022-04-02 10_41_19-192.168.1.250_4832 - Connexion Bureau à distance

#2

RAID 0 et JBOD, ce n’est pas la même chose. JBOD n’a de sens qu’avec un contrôleur RAID matériel (lorsque les disques sont accessibles indépendamment et pas en grappes RAID), pas en RAID logiciel ou par définition les disques sont accessibles indépendamment.

Non, le RAID 0 n’offre aucune redondance et si un disque meurt tout est perdu car ce qui reste sur l’autre disque est inutilisable.

Ce truc est un ramassis de conneries, et ça commence dès le titre « JBOD (raid0 non strip) ». Ça n’a aucun sens, JBOD n’est pas du RAID et le RAID 0 est du RAID en bandes par définition.

Quelles parties as-tu utilisées ? Si tu as utilisé le script de démarrage de l’ensemble RAID avec les noms de disques en dur, ce qui est une grosse connerie car ils ne sont pas stables, pas étonnant que ça pète après l’ajout d’un autre disque.

« Taille 0 octet », ça peut vouloir dire que l’ensemble RAID n’est pas démarré.

On peut voir la sortie de (en root puis copier-coller du texte, pas d’image)

cat /proc/mdstat
cat /etc/mdadm/mdadm.conf
mdadm --detail /dev/md127
blkid
lsblk
#3

Je comprend bien, mais je n’ai pas le niveau pour m’en rendre compte.
Poser la question au forum est une bonne chose, notamment pour ça je m’en rend compte, mais j’essaye de ne pas aller systématiquement embêter quelqu’un si je peux trouver l’information.

En ce sens là, aurais-tu, au delà du forum, un endroit ou je peux être bien renseigner sur le raid logiciel sous debian ?

En attendant voici le résultat des diverses commandes, en te remerciant pour le temps que tu y consacre :

Cat /proc/mdstat :

Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] [raid10] 
md126 : active raid0 sda1[0] sdb1[1]
  7813769216 blocks super 1.2 512k chunks
  
md127 : inactive sdd1[1] sdc1[0]
  3906761728 blocks super 1.2
   
unused devices: <none>

Cat /etc/mdadm/mdadm.conf :

# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/raidGA  metadata=1.2 UUID=4136c8cb:75030801:1e330467:5ff97e85 name=PiBox:raidGA
ARRAY /dev/md/raid0  metadata=1.2 UUID=9de28592:dc62fa41:d88e7a04:2f4d4b4b name=PiBox:raid0

# This configuration was auto-generated on Fri, 01 Apr 2022 20:21:20 +0200 by mkconf

mdadm --detail /dev/md127 :

       Version : 1.2
 Creation Time : Wed Oct 27 21:41:58 2021
    Raid Level : raid0
  Raid Devices : 2
 Total Devices : 2
   Persistence : Superblock is persistent

   Update Time : Wed Oct 27 21:41:58 2021
         State : active, FAILED, Not Started 
Active Devices : 2
Working Devices : 2
Failed Devices : 0
 Spare Devices : 0

        Layout : -unknown-
    Chunk Size : 512K

Consistency Policy : unknown

          Name : PiBox:raidGA  (local to host PiBox)
          UUID : 4136c8cb:75030801:1e330467:5ff97e85
        Events : 0

Number   Major   Minor   RaidDevice State
   -       0        0        0      removed
   -       0        0        1      removed

   -       8       49        1      sync   /dev/sdd1
   -       8       33        0      sync   /dev/sdc1
#4

Il manque la sortie de blkid et lsblk. Tu peux ajouter la sortie de

mdadm --examine /dev/sdc1 /dev/sdd1
#5

J’ai trouvé !

Je me suis rappeler que j’avais eu des soucis suite au montage de ce deuxième Raid.

Du coup, j’ai fais des recherches dans mon historique, j’ai trouver ça, et j’ai remis en place cette solution :

En revanche, modifier le fichier de grub c’est une chose, mettre à jour grub aussi, mais pourquoi devoir en venir à ça pour que ma partition s’ouvre, ça j’ai rien compris.

Peut être saura tu m’expliquer ? ou me dire ou je peux trouver des infos fiable pour l’avenir sur le raid, le montage, etc …

#6

Les explications du lien, notamment celles du blog, me semblent claires. Il y a aussi des explications dans les pages de manuel de mdadm à la description de l’option --layout et md à la section RAID0. Un changement dans le noyau Linux 3.14 (c’est donc très ancien) et suivants a modifié par inadvertance la disposition (layout) des données sur les disques en RAID 0 de tailles différentes. Un patch a été introduit dans le noyau 5.4 (soit bien plus tard, et rétroporté dans le noyau 4.19 de Debian buster, mais pas dans le noyau 4.9 de stretch) ajoutant le paramètre default_layout au module raid0 pour spécifier quelle est la disposition par défaut à utiliser selon que les ensembles RAID 0 ont été créés avec un noyau antérieur ou postérieur à 3.14, et empêchant d’activer un ensemble RAID 0 de ce type créé par un noyau non patché si la disposition n’est pas spécifiée car cela pourrait provoquer une corruption des données.

Concernant la valeur 1 ou 2 à donner au paramètre raid0.default_layout, elle dépend si l’ensemble RAID a été créé (ou plutôt formaté/utilisé) avec un noyau inférieur ou supérieur ou égal à 3.14. Vu la date de création de ton ensemble, c’était probablement avec un noyau supérieur. Mais de toute façon dans le cas d’un ensemble RAID 0 à seulement deux disques, il me semble qu’il n’y a aucune ambiguïté donc peu importe.

D’après la page de manuel de mdadm de bullseye il est possible d’enregistrer la disposition dans les superblocs lors de l’assemblage avec l’option --update pour que le paramètre raid0.default_layout ne soit plus nécessaire mais cela rendra l’ensemble RAID incompatible avec les noyaux anciens non patchés.

Quelle est la version de Debian sur cette machine ? Buster est un cas particulier car son noyau est patché mais sa version de mdadm ne permet pas de mettre à jour le layout à l’assemblage, donc il faut utiliser le paramètre du module raid0.

Mais a priori ce problème n’affecte que les ensembles RAID 0 dont les membres ont des tailles différentes. Or d’après ta copie d’écran les deux disques sont du même modèle donc devraient avoir la même taille, à moins que les partitions n’aient pas la même taille.

fdisk -l /dev/sdc
fdisk -l /dev/sdd
mdadm --examine /dev/sdc1 /dev/sdd1
#7

ARGGG, y’a un truc aussi qui m’énerve, depuis un moment les commandes de bases reconnu normalement à la saisie dans un terminal ne fonctionne plus.

Je suis OBLIGÉ de me rendre ou la commande se trouve et faire un ./ devant.

Tu aurais une idée aussi ?

La pour te faire fdisk, je suis aller dans /usr/sbin/

et ./fdisk -l /dev/sdc

grrrr …

Disque /dev/sdc : 1,82 TiB, 2000397852160 octets, 3907027055 secteurs
Modèle de disque : WDC WD20EFRX-68A
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 7E0DF9FD-9728-40AA-B490-C461E68448B6

Périphérique Début        Fin   Secteurs Taille Type
/dev/sdc1     2048 3907026943 3907024896   1,8T Système de fichiers Linux

./fdisk -l /dev/sdd :

Disque /dev/sdd : 1,82 TiB, 2000398934016 octets, 3907029168 secteurs
Modèle de disque : WDC WD20EFRX-68A
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 90CCDA62-456F-43E6-9C99-03E621EB3ECC

Périphérique Début        Fin   Secteurs Taille Type
/dev/sdd1     2048 3907028991 3907026944   1,8T Système de fichiers Linux
root@PiBox:/usr/sbin# ./fdisk -l /dev/sdd
Disque /dev/sdd : 1,82 TiB, 2000398934016 octets, 3907029168 secteurs
Modèle de disque : WDC WD20EFRX-68A
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 90CCDA62-456F-43E6-9C99-03E621EB3ECC

Périphérique Début        Fin   Secteurs Taille Type
/dev/sdd1     2048 3907028991 3907026944   1,8T Système de fichiers Linux

enfin mdadm --examine /dev/sdc1 /dev/sdd1

/dev/sdc1     2048 3907026943 3907024896   1,8T Système de fichiers Linux
root@PiBox:/usr/sbin# ./mdadm --examine /dev/sdc1 /dev/sdd1
/dev/sdc1:
      Magic : a92b4efc
    Version : 1.2
Feature Map : 0x0
 Array UUID : 4136c8cb:75030801:1e330467:5ff97e85
       Name : PiBox:raidGA  (local to host PiBox)
Creation Time : Wed Oct 27 21:41:58 2021
 Raid Level : raid0
 Raid Devices : 2

 Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=0 sectors
      State : clean
Device UUID : 0baf1b8f:4a87d06e:1b87313a:01aff774

Update Time : Wed Oct 27 21:41:58 2021
Bad Block Log : 512 entries available at offset 8 sectors
   Checksum : cd6cfd76 - correct
     Events : 0

 Chunk Size : 512K

Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
      Magic : a92b4efc
    Version : 1.2
Feature Map : 0x0
 Array UUID : 4136c8cb:75030801:1e330467:5ff97e85
       Name : PiBox:raidGA  (local to host PiBox)
 Creation Time : Wed Oct 27 21:41:58 2021
 Raid Level : raid0
 Raid Devices : 2

Avail Dev Size : 3906762752 (1862.89 GiB 2000.26 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=0 sectors
      State : clean
Device UUID : 9bc8e97d:1a2b31f5:f8b3f3c8:188a4815

Update Time : Wed Oct 27 21:41:58 2021
Bad Block Log : 512 entries available at offset 8 sectors
   Checksum : 71aecacc - correct
     Events : 0

 Chunk Size : 512K

Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
#8

Vacherie, les deux disques sont du même modèle mais ont une différence de capacité de 1 Mio (de même que leurs partitions respectives), ce qui suffit à les faire considérer comme de tailles différentes pour le RAID0. Il aurait suffi que les deux partitions aient exactement la même taille pour que le problème ne se produise pas.

Le layout n’est pas défini dans les superblocs RAID, d’où la nécessité de passer le paramètre du noyau. Si tu es sûr de ne jamais utiliser cet ensemble RAID avec un noyau antérieur non patché tu peux définir le layout une fois pour toutes lors d’un assemblage manuel, ça évitera de devoir spécifier le paramètre du noyau à chaque fois.

mdadm --stop /dev/md127
mdadm --assemble /dev/md/raidGA /dev/sdc1 /dev/sdd1 --update=layout-alternate

$PATH incomplet. Tu ne passerais pas root avec « su » au lieu de « su - » ?

2 J'aime
#9

Déjà, je te remercie pour le temps consacré à mes diverses demandes.

J’ai fais quelque recherche sur su et su -, il s’avère qu’en toute logique si je charge pas les variables d’environnement, forcément je vais pas savoir si certaines commandes existent, merci de m’avoir fait remarquer qu’en su - ça fonctionne.

Aussi, je sais pourquoi ça à finit comme ça, j’ai ressorti certaines factures de disques, et TADA, un des deux disque de 2To est parti en garanti 1 ans après la vente. Ce qui fait que, ils n’ont pas le même âge, et que bien qu’ils soient sur le papier du même modèle … ^^, visiblement pas, à 1 Mio prêt.

J’avais créer ce raid sous Buster, aujourd’hui je suis sous Bullseye.

Je vais m’occuper cet après midi de définir le layout au niveau des superbloc.

Si je comprend bien, définir le layout dans les superbloc sous entend, définir que un disque va nécessairement avec l’autre, ceci sur chacun des disques ?

#10

Non, le fait que les deux disques font partie d’un ensemble RAID0 est déjà enregistré dans les superblocs. Définir le layout consiste à indiquer quelle est la disposition des blocs dans les zones supplémentaires des disques dont la taille est supérieure à celles des autres. On peut enregistrer le layout directement dans les superblocs à la création de l’ensemble ou lors de l’assemblage avec mdadm, ou bien spécifier un layout par défaut dans le paramètre default_layout du module raid0.

Exemple (pas forcément réaliste) avec trois disques A, B et C :

  • un disque A de taille 1 To
  • deux disques B et C de taille 2 To
  • taille totale de l’ensemble RAID0 = 1 + 2 + 2 = 5 To

L’ensemble RAID0 de 5 To est donc divisé en deux zones :

  • une zone répartie sur 1 To des trois disque (3 To au total)
  • une zone répartie sur le To restant des disques B et C (2 To au total)

Dans la première zone, il n’y a pas d’ambiguïté sur la disposition des blocs entre les trois disques. Par contre dans la seconde zone, il y a deux dispositions possibles selon que l’ensemble RAID0 a été créé avec un noyau pré ou post-3.14 :

  • un bloc sur B puis le bloc suivant sur C et ainsi de suite
  • ou bien un bloc sur C puis le bloc suivant sur B et ainsi de suite

Si on indique le mauvais layout, les blocs de la deuxième zone vont être recherchés sur le mauvais disque.

Ce que je trouve un peu dommage, c’est que dans le cas où un seul disque est plus grand que les autres (et notamment quand il n’y a que deux disques), le layout est sans objet puisque tous les blocs supplémentaires sont forcément sur ce disque. Il me semble que le code aurait pu être optimisé pour ne pas exiger un layout explicite dans les cas où il n’y a pas d’ambiguïté.

1 J'aime
#11

J’ai posé la question à l’auteur du patch qui a introduit le layout en RAID0, il a été d’accord avec moi et m’a suggéré de soumettre un patch. Mon modeste patch vient d’être accepté par le mainteneur du RAID logiciel (md) du noyau.
https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/commit/?h=md-next&id=190a901246c69d79dadd1ab574022548da612724

Par contre ce patch sera seulement inclus dans une future version du noyau (a priori 5.19, la version 5.18 étant déjà en phase rc), il faudra ensuite demander de le rétroporter dans les séries stables encore maintenues, dont la série 5.10 de bullseye.

3 J'aime
#12

Et bah je te remercie, je sais que c’est open source mais j’ai pour l’instant pas le niveau de proposer un patch ou même de lire du code sur des petits bouts comme ça.

J’ai lu ton correctif pour autant, il semble que ce soit du C++ ?

J’ai bien assemblé les disques et vérifier que ça marche, j’ai supprimer les paramètres de lancement du kernel sur ce point.

#13

La majeure partie du code source du noyau Linux est écrite en langage C, pas en C++. Certaines parties spécifiques aux architectures des processeurs ou devant être optimisées sont écrites en assembleur. Le patch lui-même est au format « diff »(du nom de la commande traditionnelle qui le génère) et contient les différences entre le code originel et le code modifié., et peut être appliqué avec la commande « patch ».

Je n’ai pas non plus le niveau pour proposer autre chose que des patchs triviaux comme celui-ci. S’il a l’air si gros, c’est en fait parce que j’ai dû déplacer tout un bloc de code existant, mais l’ajout de code effectif ne porte que sur une ligne. C’était plus un exercice de style qu’autre chose pour moi ; le plus important était de signaler la régression introduite par le changement originel, n’importe quel développeur du noyau aurait ensuite pu écrire le patch.

Je pense que tu peux marquer le sujet comme résolu avec la case à cocher correspondante.

1 J'aime
#14

Le patch a bien été inclus dans la nouvelle version 5.19 et vient d’être rétroporté dans les séries stables/longterm maintenues, dont 4.19 (4.19.247) et 5.10 (5.10.122). Il devrait donc être inclus dans de futures mises à jour des noyaux de buster et bullseye basés sur ces séries. C’est d’autant plus utile pour buster dont la version de mdadm ne gère pas le layout RAID0.

#15

Ça y est :

  • noyau 4.19.0-21 publié récemment pour Buster comme mise à jour de sécurité DSA 5173-1
  • noyau 5.10.0-16 publié aujourd’hui pour Bullseye avec la mise à niveau 11.4
1 J'aime