Différence entre l'UUID de blkid et mdadm?

Quelqu'un peut-il expliquer la différence entre les UUID rapportés par blkidet mdadm? Sur l'un de nos systèmes CentOS, par exemple:

[root@server ~]# blkid | grep /dev/md1
/dev/md1: UUID="32cb0a6e-8148-44e9-909d-5b23df045bd1" TYPE="ext4"

[root@server ~]# mdadm --detail /dev/md1 | grep UUID
UUID : f204c558:babf732d:85bd7296:bbfebeea

Pourquoi sont-ils différents et comment changerions-nous l'UUID utilisé par mdadm?

Je comprends que nous utiliserions tune2fspour changer l'UUID de la partition (ce qui changerait ce qui est retourné par blkid), mais je ne sais pas comment changer ce qui est mdadmutilisé.

Le premier signale l'UUID du système de fichiers ext4 sur le mdpériphérique de bloc. Il aide le système à identifier le système de fichiers de manière unique parmi les systèmes de fichiers disponibles sur le système. Cela est stocké dans la structure du système de fichiers, c'est-à-dire dans les données stockées sur le périphérique md.

Le second est l'UUID du périphérique RAID. Il aide le sous-système md à identifier ce périphérique RAID particulier de manière unique. En particulier, il permet d'identifier tous les périphériques de bloc qui appartiennent à la matrice RAID. Il est stocké dans les métadonnées du tableau (sur chaque membre). Les membres de groupe ont également leur propre UUID (dans le système md, ils peuvent également avoir des UUID de partition s'il s'agit de partitions GPT (qui elles-mêmes seraient stockées dans la table de partition GPT), ou de volumes LVM ...).

blkidest un peu trompeur, car il renvoie l'ID de la structure stockée sur le périphérique (pour ce type de structures qu'il connaît comme la plupart des systèmes de fichiers, des membres LVM et des périphériques d'échange). Notez également qu'il n'est pas rare d'avoir des périphériques de bloc avec des structures avec des UUID identiques (par exemple des instantanés LVM). Et un périphérique bloc peut contenir n'importe quoi, y compris des éléments dont la structure ne comprend pas d'UUID.

Ainsi, à titre d'exemple, vous pourriez avoir un système avec 3 disques, avec partitionnement GPT. Ces disques pourraient avoir un nom universel qui l'identifie de manière unique. Disons que les 3 disques sont partitionnés avec une partition chacun ( /dev/sd[abc]1). Chaque partition aura un UUID GPT stocké dans la table de partition GPT.

Si ces partitions constituent une matrice md RAID5. Chacun recevra un md UUID en tant que membre RAID, et la baie obtiendra un UUID en tant que périphérique RAID md.

Cela /dev/md0peut être encore partitionné avec un partitionnement de type MSDOS ou GPT. Par exemple, nous pourrions avoir une /dev/md0p1partition avec un UUID GPT (stocké dans la table de partition GPT qui est stockée dans les données de / dev / md0).

Cela pourrait à son tour être un volume physique pour LVM. En tant que tel, il obtiendra un UUID PV. Le groupe de volumes aura également un UUID VG.

Dans ce groupe de volumes, vous créeriez des volumes logiques, chacun obtenant un UUID LV.

Sur l'un de ces LV (comme /dev/VG/LV), vous pouvez créer un système de fichiers ext4. Ce système de fichiers obtiendrait un UUID ext4.

blkid /dev/VG/LVvous obtiendrait l'UUID (ext4) de ce système de fichiers. Mais en tant que partition à l'intérieur du volume VG, il obtiendrait également un UUID de partition (certains schémas de partitionnement comme MSDOS / MBR n'ont pas d'UUID). Ce groupe de volumes est composé de PV membres qui sont eux-mêmes d'autres périphériques de bloc. blkid /dev/md0p1vous donnerait l'UUID PV. Il a également un UUID de partition dans la table GPT /dev/md0. /dev/md0lui-même est fabriqué à partir d'autres périphériques de bloc. blkid /dev/sda1renverra l'UUID du membre du raid. Il a également un UUID de partition dans la table GPT /dev/sda.

Les différents UUID ont déjà été expliqués. Non seulement les systèmes de fichiers en ont. Il y a juste des UUID pour différentes choses: tableau RAID, périphérique, partition, conteneurs LUKS, PV LVM ... et enfin systèmes de fichiers.

Ce qui m'agace personnellement, c'est que même la façon dont ces UUID sont formatés est différente.

blkid:

# blkid /dev/sda1
/dev/sda1: 
UUID="d8b8b4e5-e47b-2e45-2093-cd36f654020d"
UUID_SUB="3c3e6eac-2139-3f7a-16b7-57280934d88e"
PARTUUID="6a89cedf-69e1-40db-b08c-1c8e45af59f5" 

mdadm:

# mdadm --examine /dev/sda1 | grep UUID
     Array UUID : d8b8b4e5:e47b2e45:2093cd36:f654020d
    Device UUID : 3c3e6eac:21393f7a:16b75728:0934d88e

Comme vous pouvez le voir, ce sont les mêmes UUID, mais les blkidimprime avec des tirets -alors qu'il mdadmutilise des deux-points :. Vous obtenez donc d8b8b4e5-e47b-2e45-2093-cd36f654020dcontre d8b8b4e5:e47b2e45:2093cd36:f654020d.

Très ennuyeux, surtout si vous souhaitez travailler avec des UUID dans des scripts. La conversion d'un formatage à l'autre n'est pas évidente.

L'UUID blkid ci-dessus "32cb0a6e-8148-44e9-909d-5b23df045bd1" est le bon, c'est ce que l'OS utilisera pour trouver la matrice RAID.

mdadm possède son propre UUID "interne" qui n'est pas utilisé directement par le système d'exploitation et correspond à ce que vous utilisez dans le fichier mdadm.conf, par exemple:

"ARRAY / dev / md1 level = raid1 num-devices = 2 uuid = f204c558: babf732d: 85bd7296: bbfebeea"

mdadm ne devrait pas appeler quoi que ce soit UUID quand il est distinct de celui que blkid et le système d'exploitation reconnaissent. Peut-être qu'il devrait s'appeler mduuid ou autre chose pour éviter toute confusion.