Eu criei um RAID1 com
mdadm --create /dev/mdX --level=mirror --raid-devices=2 /dev/sdb /dev/sdc
Em seguida, assisti à primeira sincronização em /proc/mdstat . Diz [UU] . Até aí tudo bem.
sd[bc] deveria ter sido shred ed, mas eu não verifiquei antes, imaginando que todos os conteúdos seriam sobrescritos de qualquer maneira.
Eu comecei a criar um grupo de volume nesse dispositivo e, em seguida, criei um ext4 FS em um novo volume lógico.
Querendo montar via UUID, eu despejei todos eles com blkid . Já visualmente a matriz RAID1 parecia "off".
blkid (apenas linhas relevantes mostradas):
/dev/mdX: UUID="..." TYPE="LVM2_member"
/dev/sdb: UUID="..." UUID_SUB="..." LABEL="...:0" TYPE="linux_raid_member"
/dev/sdc1: PARTUUID="0xd25946fb"
Eu estava esperando 2 "linux_raid_members", e o que é com /dev/sdc1 ? Eu novamente confiro:
# cat /proc/mdstat (shortened)
Personalities : [raid1]
mdX : active raid1 sdb[0] sdc[1]
976631488 blocks super 1.2 [2/2] [UU]
bitmap: 2/8 pages [8KB], 65536KB chunk
# cat /proc/partitions (shortened)
major minor #blocks name
8 32 976762584 sdc
8 33 976759808 sdc1
8 16 976762584 sdb
9 0 976631488 md0
# fdisk -l /dev/sd[bc]
Disk /dev/sdb: (empty, as expected, both disk geoms identical, also expected)
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xd25946fb
Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 1953521663 1953519616 931.5G 7 HPFS/NTFS/exFAT
Novamente sdc1 .
Portanto, parece que sdc nunca foi destruído. Mas todas as informações de metadados / partições anteriores não devem ser substituídas por mdadm --create ? Pensando que pode ser uma informação em cache, eu corro partprobe . Nenhuma mudança. Eu tento reboot , sem alteração. Então, parece que ainda há uma tabela de partições na unidade.
Tenho algumas ideias e decido publicá-las em SE.
Então, enquanto escrevia este post, eu queria postar um comando blkid mais "preciso", então eu executei blkid /dev/sd[bc]{,1} /dev/mdX e o colei neste post:
/dev/sdb: UUID="..." UUID_SUB="..." LABEL="...:0" TYPE="linux_raid_member"
/dev/sdc: UUID="..." UUID_SUB="..." LABEL="...:0" TYPE="linux_raid_member"
/dev/sdc1: PARTUUID="d25946fb-01"
/dev/mdX: UUID="..." TYPE="LVM2_member"
Na pré-visualização deste post eu vi que era muito "regular", e -lo e eis que o segundo membro RAID! Duvidando da minha sanidade, executei blkid sem parâmetros novamente. sdc , o segundo membro RAID não é mostrado.
Neste ponto, meus problemas parecem se resumir a:
Como faço para me livrar da tabela de partição (com segurança), e eu vou então pegar meu segundo membro de raid em blkid w / o parameters? Que outros problemas poderiam surgir se eu simplesmente deixar isso acontecer? Neste momento, parece que o meu RAID1 está operacional, mas é? Como eu testaria melhor isso?
As ideias que desenvolvi até agora incluem:
dd if=/dev/zero bs=512 count=1 of=/dev/sdc e execute partprobe e blkid depois. Mas isso não trará qualquer mdadm ou qualquer outra coisa de alguma forma? Sem o U.SE eu provavelmente teria tentado 1) e depois 2), tendo certeza de que 2) funcionaria, mas seria o menos elegante e mais demorado.
Os dados sobre esse md não são vitais e, na ausência de respostas, tentarei 1) e depois 2). Eu vou postar resultados. Mas ainda estarei interessado em saber por que sdc não é mostrado como raid-member com blkid , enquanto ele é mostrado com blkid /dev/sd[bc] , enquanto sdb é mostrado em ambos os casos.
Acredito que o problema que você está enfrentando é que os dados gravados em um membro do RAID sejam parecidos com uma tabela de partição. A correção é simplesmente ignorar as partições e continuar independentemente disso. Provavelmente, existe uma maneira de definir um "deslocamento de dados" para todos os membros do RAID para evitar esse problema.