Sur les systèmes plus récents /usr/share/mdadm/mkconf
(le script utilisé pour générer /etc/mdadm/mdadm.conf
) a tendance à utiliser le nom du périphérique /dev/md/0
au lieu de /dev/md0
:
new-system ~ # /usr/share/mdadm/mkconf | grep ARRAY
ARRAY /dev/md/0 metadata=1.2 UUID=a0021927:0e4f10bf:2c47dc72:ca0b352e name=unassigned:0
Cela peut provoquer une certaine irritation pour les utilisateurs qui /dev/md0
s'y attendent , mais apparemment, cela fonctionne bien car le serveur démarre sans problème.
Dans /proc/mdstat
l'appareil est toujours appelé /dev/md0
:
new-system ~ # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[2] sda2[0]
1953381184 blocks super 1.2 [2/2] [UU]
unused devices: <none>
ls
montre qu'il /dev/md/0
s'agit d'un lien symbolique vers /dev/md0
:
new-system ~ # ls -l /dev/md/0
lrwxrwxrwx 1 root root 6 Nov 20 14:06 /dev/md/0 -> ../md0
Sur un autre système plus ancien, mkconf
il utilise toujours à la /dev/md0
place et /dev/md
est vide:
old-system ~ # /usr/share/mdadm/mkconf | grep ARRAY
ARRAY /dev/md0 UUID=76472cf5:83fd8e5a:ad617046:69b2ebf1
old-system ~ # ls -l /dev/md
total 0
Je voudrais connaître la différence entre ces noms d'appareils et je ne trouve aucune explication sur Google. Est-ce /dev/mdN
l'ancien nom et md
prévoit de passer aux /dev/md/N
noms de périphérique? Ce changement est-il lié aux métadonnées 1.2 (j'ai remarqué que le nouveau serveur utilise md 1.2, tandis que l'ancien utilise toujours 0.90)?
EDIT 2017-09-11: Je pense que la réponse de Krzysztof Stasiak est la bonne. J'avais maintenant totalement oublié cette question. Vendredi dernier, en jouant avec un RAID de test, j'ai pensé "pourquoi ne pas nommer ma baie au lieu de mémoriser ce que md0, md1, md2, ... etc. font dans des configurations complexes?", Et j'ai donc essayé:
test-server ~ # mdadm --assemble /dev/mdfoobar /dev/loop[01]
mdadm: /dev/mdfoobar is an invalid name for an md device. Try /dev/md/mdfoobar
Et en effet cela fonctionne:
test-server ~ # mdadm --assemble /dev/md/foobar /dev/loop[01]
mdadm: /dev/md/foobar has been started with 2 drives.
test-server ~ # ll /dev/md/foobar
lrwxrwxrwx 1 root root 6 Sep 11 10:45 /dev/md/foobar -> ../md0
test-server ~ # cat /proc/mdstat
Personalities : [raid1]
md0 : active (auto-read-only) raid1 loop0[0] loop1[1]
102272 blocks super 1.2 [2/2] [UU]
unused devices: <none>
(Vous pouvez également le faire mdadm --assemble foobar DEV...
).
Il y a une explication détaillée dans la man mdadm
section DEVICE NAMES
.
mdadm -E
qui se trouve actuellementunassigned:0
sur le nouveau serveur est divisé à la:
, et la deuxième partie devient une partie du/dev/md/<name>
? Donc, si je changeais le nom du tableauunassigned:asdf
, le lien symbolique serait appelé/dev/md/asdf
? Et l'appareil réel est toujours appelé/dev/mdN
, où N est le prochain numéro gratuit?unassigned:0
est juste braindead.Réponses:
vous pouvez nommer le tableau en tant que nom propre (pas seulement 0-127) et depuis mdadm 3.0.3, vous ne pouvez utiliser que le nom. Si think path a été modifié pour utiliser le sous-dossier
/dev/md/$name
pour plus de flexibilité ou une sorte de tableaux propres ou groupés. Si le tableau md est créé au format/dev/mdX
, un lien symbolique est ajouté pour rendre la compatibilité avec le nouveau format.la source
En ce qui concerne les noms de périphériques, mieux vaut demander à udev . À ma connaissance,
md%d
le nommage est utilisé par le noyau, il est généré directement par le pilote md.c # L5284 , et il est utilisé dans/proc/partitions
etsysfs
. Par conséquent, il apparaît dans/dev
/dev/md/...
et/dev/disk/by-id/...
sont générés sous forme de liens symboliques par udevd. Dans mon système, les règles correspondantes sont conservées dans/usr/lib/udev/rules.d/63-md-raid-arrays.rules
:Il semble que udev fichier provient de
openSUSE 11.1-rc3
selon cette engagement dans mdadm. J'ai archivé ce fichieropenSUSE 11.0
, mais il n'a pas demd/%d
liens symboliques ...la source
Le chemin d'origine varie probablement selon la version du noyau Linux ou le système Unix. Le lien symbolique
/dev/md/N
peut exister pour des raisons de compatibilité. Programmes ou scripts qui peuvent utiliser ce chemin au lieu de/dev/mdN
.la source