несоответствия mdadm, когда выполнено программно
TL;DR.
Я узнал, в чем проблема! Мне пришлось спать некоторое время между некоторыми из задач разбиения. Очевидно, я наткнулся на проблемы с параллельностью.
Глубина:
Похоже, что когда процесс завершается, это не значит, что ядро уже выполнило свою роль в процессе (в случае, если ядро должно что-то сделать после данного процесса). В моем случае это была разметка - видимо, я начал mdadm --create слишком рано, когда ядро еще не обновило некоторые изменения раздела. И да, между ними была partprobe, но, похоже, он тоже не знает об изменениях.
Я начал отлаживать это с помощью скриптов оболочки, клиповых php-скриптов, веб-скриптов, пока не наткнулся на:
[root@stone /] parted -s /dev/sdb mklabel gpt unit GB mkpart primary 0 100%
[root@stone /] parted -s /dev/sdc mklabel gpt unit GB mkpart primary 0 100%
[root@stone /] partprobe
[root@stone /] lsblk
sda 8:0 0 55.9G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 500M 0 part /boot/efi
├─sda3 8:3 0 500M 0 part [SWAP]
└─sda4 8:4 0 54.9G 0 part /
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part
sdc 8:32 0 931.5G 0 disk
Когда команды выполнялись без интервалов между ними, что позволяло процессору обрабатывать их как можно быстрее - я заметил, что /dev/sdc еще не обновил таблицу разделов.
Видимо, следующей командой после этой partprobe является mdadm --creatate, которая стартовала без изменений таблицы разделов, что привело к странному поведению.
Может быть, мои наблюдения и предположения совершенно неверны, но, по крайней мере, так я могу объяснить ситуацию логически для себя.
Да, исправление заключалось в добавлении сна между вызовами:
[root@stone /] parted -s /dev/sdb mklabel gpt unit GB mkpart primary 0 100%
[root@stone /] parted -s /dev/sdc mklabel gpt unit GB mkpart primary 0 100%
[root@stone /] sleep 1
[root@stone /] partprobe
[root@stone /] sleep 1
[root@stone /] lsblk
sda 8:0 0 55.9G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 500M 0 part /boot/efi
├─sda3 8:3 0 500M 0 part [SWAP]
└─sda4 8:4 0 54.9G 0 part /
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part
sdc 8:32 0 931.5G 0 disk
Это исправило проблему.
В конце концов, однако, я до сих пор не могу найти логического объяснения тому, почему в случае RAID0 он не сделал симлинк, где он сделал в случае RAID1. Я просто не могу понять, что такое готовность дисков, которая препятствует созданию symlink...