Различие между UUID от blkid и mdadm?
Я нашел фиксацию для этого. Если у Вас есть та же проблема, попробуйте это. Перед конфигурированием попробуйте это в своей gcc папке:
./contrib/download_prerequisites
Первый сообщает UUID файловой системы ext4 на блочном устройстве md . Это помогает системе однозначно идентифицировать файловую систему среди файловых систем, доступных в системе. Это хранится в структуре файловой системы, то есть в данных, хранящихся на устройстве MD.
Второй - это UUID RAID-устройства. Это помогает подсистеме md однозначно идентифицировать это конкретное устройство RAID. В частности, он помогает идентифицировать все блочные устройства, принадлежащие массиву RAID. Он хранится в метаданных массива (на каждом члене). Члены массива также имеют свой собственный UUID (в системе md они также могут иметь UUID разделов, если они являются разделами GPT (которые сами по себе будут храниться в таблице разделов GPT) или тома LVM ...).
blkid немного вводит в заблуждение, поскольку он возвращает идентификатор структуры, хранящейся на устройстве (для таких структур, о которых он знает, как большинство файловых систем, элементы LVM и устройства подкачки). Также обратите внимание, что нередко встречаются блочные устройства со структурами с идентичными UUID (например, снимки состояния LVM). А блочное устройство может содержать что угодно, включая вещи, в структуру которых не входит UUID.
Так, например, у вас может быть система с 3 дисками с разделением GPT.Эти диски могут иметь всемирное имя , которое однозначно идентифицирует их. Допустим, 3 диска разбиты на разделы по одному разделу каждый ( / dev / sd [abc] 1 ). У каждого раздела будет GPT UUID, хранящийся в таблице разделов GPT.
Если эти разделы составляют массив MD RAID5. Каждый получит md UUID как член RAID, а массив получит UUID как md RAID-устройство.
Этот / dev / md0 может быть дополнительно разбит на разделы с помощью MSDOS или GPT. Например, у нас может быть раздел / dev / md0p1 с GPT UUID (хранится в таблице разделов GPT, которая хранится в данных / dev / md0).
Это, в свою очередь, может быть физический том для LVM. Таким образом, он получит UUID PV. Группа томов также будет иметь VG UUID.
В этой группе томов вы должны создать логические тома, каждый из которых получит LV UUID.
На одном из этих LV (например, / dev / VG / LV ) вы можете создать файловую систему ext4. Эта файловая система получит UUID ext4.
blkid / dev / VG / LV даст вам (ext4) UUID этой файловой системы. Но как раздел внутри тома VG он также получит UUID раздела (некоторые схемы разделения, такие как MSDOS / MBR, не имеют UUID). Эта группа томов состоит из PV участников, которые сами являются другими блочными устройствами. blkid / dev / md0p1 предоставит вам UUID PV. У него также есть UUID раздела в таблице GPT на / dev / md0 . / dev / md0 сам создан из других блочных устройств. blkid / dev / sda1 вернет UUID участника рейда.У него также есть UUID раздела в таблице GPT на / dev / sda .
Лично меня раздражает то, что даже способ форматирования этих UUID отличается.
blkid:
- mdadm:
- Как видите, это те же самые UUID, но [1128202]blkid[1128203] печатает их тире [1128204]-[1128205], в то время как [1128206]mdadm[1128207] использует двоеточия [1128208]:[1128209]. Таким образом, вы получаете [1128210]d8b8b4e5-e47b-2e45-2093-cd36f654020d[1128211] против [1128212]d8b8b4e5:e47b2e45:2093cd36:f654020d[1128213].
- Очень раздражает, особенно если вы хотите работать с UUIDs в скриптах. Не совсем понятно, как конвертировать из одного форматирования в другое[1127848].
mdadm имеет свой "внутренний" UUID, который не используется непосредственно операционной системой, а используется в mdadm. conf file eg:
"ARRAY /dev/md1 level=raid1 num-devices=2 uuid=f204c558:babf732d:85bd7296:bbfebeea"
