Vamos apenas seguir em frente e testar isso no ArchLinux e no mdadm. Mas antes de tudo isso não deveria importar para arrays baseados em partições, porque então as partições membros têm seus próprios UUIDs, então isso, em teoria, só se aplica a membros inteiros do disco.
TL; DR: Este não é um problema real, mesmo com blocos de metadados antigos. Pode ter sido um bug em um software antigo que eu não conheço. Mas isso não afeta um ArchLinux moderno.
#uname -sr
Linux 4.14.7-1-ARCH
#modprobe raid1
#mdadm --create --verbose /dev/md0 --metadata 0.9 --level=mirror --raid-devices=2 /dev/sdb /dev/sdd
mdadm: size set to 102336K
mdadm: array /dev/md0 started.
#cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdd[1] sdb[0]
102336 blocks [2/2] [UU]
unused devices: <none>
#mdadm --detail --scan >> /etc/mdadm.conf
fdisk /dev/md0
lsblk /dev/md0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 100M 0 disk
└─md0 9:0 0 100M 0 raid1
└─md0p1 259:0 0 98.9M 0 md
sdd 8:48 0 100M 0 disk
└─md0 9:0 0 100M 0 raid1
└─md0p1 259:0 0 98.9M 0 md
md0 8:0 0 100M 0 raid1
└─sda2 8:2 0 98.9M 0 md
mdstat - > [UU]
#blkid /dev/md0
/dev/md0: PTUUID="d49d8666-e580-8244-8c82-2bc325157e66" PTTYPE="gpt"
#blkid /dev/sdd
/dev/sdd: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"
#blkid /dev/sdb
/dev/sdb: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"
#mkfs.ext4 /dev/md0p1
mke2fs 1.43.7 (16-Oct-2017)
creating filesystem with 101292 1k blocks and 25376 inodes
Filesystem UUID: 652bcf77-fe47-416e-952c-bbOa76a78407
Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
#mount /dev/md0p1 /mnt
#lsblk -o NAME,UUID,MOUNTPOINT /dev/sdb /dev/sdd
NAME UUID MOUNTPOINT
sdb b3d82551-0226-6687-8279-b6dd6ad00d98
└─md0
└─md0p1 652bcf77-fe47-416e-952c-bbOa76a78407 /mnt
sdd b3d82551-0226-6687-8279-b6dd6ad00d98
└─md0
└─md0p1 652bcf77-fe47-416e-952c-bbOa76a78407 /mnt
Até aí tudo bem. Isso não apenas identifica corretamente os dispositivos membros como dispositivos RAID, mas também há dois UUIDs no nível da partição correspondentes. Na verdade, eles fazem parte do mesmo dispositivo de contêiner md0 e listam o mesmo ponto de montagem. NÃO lista nenhum contêiner de partição normal em sdd ou sdb. Note que o próprio dispositivo md0 NÃO possui um UUID. Apenas seus membros têm o UUID e, na verdade, o mesmo UUID.
#echo "UUID=652bcf77-fe47-416e-952c-bbOa76a78407 /mnt ext4 rw,relatime,data=ordered 0 2" >> /etc/fstab
umount /mnt
mount /mnt
cd /mnt
fallocate -l 50MiB data
mdstat - > [UU]
Lembrando que pedimos o UUID do sistema de arquivos dos membros do raid agora vamos tentar executar o sistema sem o mdadm em execução.
#cd
#umount /mnt
#mdadm --stop /dev/md0
mdadm: stopped /dev/md0
#lsblk /dev/sdb /dev/sdd
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 100M 0 disk
sdd 8:48 0 100M 0 disk
Agora, o sistema acha que esses discos são corretamente raw porque não têm tabela de partição e, portanto, não são contêineres. No entanto, se perguntarmos sobre o que são:
#blkid /dev/sdd
/dev/sdd: UUID="b3d82551-0226-6687-8279-b6dd6ad00d98" TYPE="linux_raid_member"
Ainda é um linux_raid_member e se tentarmos montá-lo:
#mount /dev/sdd /mnt
mount /mnt: unknown filesystem type "linux raid member"
Que tal:
#mount /mnt
mount: /mnt can't find UUID=652bcf77-fe47-416e-952c-bbOa76a78407
E isso faz sentido porque o sdd NÃO é um contêiner e, portanto, não há sistemas de arquivos que são analisados. No entanto, se eu correr:
#mdadm --assemble --scan && mount /mnt
mdadm: /dev/md0 has been started with 2 drives.
E se eu pará-lo novamente e remover o mdadm.conf:
#umount /mnt && mdadm --stop /dev/md0
#modprobe -r raid1
#rm /etc/mdadm.conf
#modprobe raid1
#mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 2 drives.
Note que minha configuração para o nome do dispositivo md0 não está mais entrando em vigor e está sendo criada em / dev / md / 0 automaticamente. Agora vamos reiniciar e ver o que o systemd / Linux faz com o fstab.
#mdadm --stop /dev/md/0
mdadm: stopped /dev/md/0
#systemctl reboot
#dmesg | grep md0
[ 14.550231] md/raidl:md0: active with 2 out of 2 mirrors
[ 14.550261] md0: detected capacity change from 0 to 104792064
[ 14.836905] md0: p1
[ 16.909057] EXT4-fs (md0p1): mounted filesystem with ordered data mode. Opts: data=ordered
#lsblk /dev/md0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
md0 9:0 0 100M 0 raidl
└─md0p1 259:0 0 98.9M 0 md /mnt
E novamente com o parâmetro do kernel raid = noautodetect pois isso também simularia versões do Linux que não detectariam automaticamente todas as invasões e em todas as versões de superblocos / metadados etc. Ainda assim, monta a invasão porque eu pedi no fstab e force carregado mod raid1. Então vamos tentar novamente com o black listado com modprobe.blacklist = raid1:
Ok,entãooqueestáacontecendo?:
Então,olinuxsabequeéumdispositivodotiporaid,mesmoquenãotenhasuportearaid.Aotentarmontá-lo,eledetectacorretamenteseudispositivoraide,aousarofstab,elenãoencontraoUUID,apesardeestarnosuperblocodesistemasdearquivos.
Emaisumavez!Seminformaçõesemfstaboumdadm.
#mount/dev/sdd/mntmount:/mnt:unknownfilesystemtype"linux_raid_member".
Eu acho que a essência disso não é apenas a análise do Linux é inteligente. Além disso, usando ferramentas como o fdisk, que há informações extras na área da tabela de partições. Você teria que se esforçar muito para cometer esse erro no UUID do seu sistema de arquivos para um dos discos membros.