I created a RAID1 with
mdadm --create /dev/mdX --level=mirror --raid-devices=2 /dev/sdb /dev/sdc
Then watched the first sync on /proc/mdstat. It says [UU]. So far so good.
sd[bc] were supposed to have been shreded, but I did not check before, figuring that all contents were going to be overwritten anyway.
I proceeded to create a volume group on that device, and then created an ext4 FS in a fresh logical volume.
Wanting to mount via UUID, I dumped them all with blkid. Already visually the RAID1 array looked "off".
blkid (only relevant lines shown):
/dev/mdX: UUID="..." TYPE="LVM2_member"
/dev/sdb: UUID="..." UUID_SUB="..." LABEL="...:0" TYPE="linux_raid_member"
/dev/sdc1: PARTUUID="0xd25946fb"
I was expecting 2 "linux_raid_members", and whats with /dev/sdc1? I again check:
# 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
Again sdc1.
So it looks like sdc was never shredded. But shouldn't all previous meta-data/partition info be overwritten by mdadm --create? Thinking it may be cached info, I run partprobe. No change. I try reboot, no change. So, It looks like there still is a partition table on the drive.
I have a few ideas, and I decide to post this to SE.
So, while writing this post, I wanted to post a more "precise" blkid command, so I executed blkid /dev/sd[bc]{,1} /dev/mdX, and pasted it into this 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"
In the preview for this post I saw that it was too "regular", and -lo and behold- spotted the second RAID-Member! Doubting my sanity, I executed blkid without parameters again. sdc, the second RAID-member is not shown.
At this point my problems seems to boil down to:
How do I get rid of the partition table (safely), and will I then get my second raid-member in blkid w/o parameters? What other problems could arise if i just leave this be? At this point it looks like my RAID1 is operational, but is it? How would I best test that?
The ideas I had built up up to and including now are:
- Bulldoze online:
dd if=/dev/zero bs=512 count=1 of=/dev/sdcand runpartprobeandblkidafterwards. But wont that trip up anymdadmor anything else somehow? - fail the member, disconnect (logically), bulldoze first few MiBs off-line, reconnect (logically), re-synchronize. I'd rather not.
- Find out through SE about the "standard" way of dealing with leftover meta-data only found after array creation.
Without U.SE I would probable have tried 1) and then 2), being fairly sure that 2) would work, but be the least elegant and most lengthy way.
The data on that md is not vital, and in the absence of answers I will try 1) then 2). I will post results. But I'll still be interested in knowing why sdc does not get shown as raid-member with blkid, while it does get shown with blkid /dev/sd[bc], whereas sdb is shown in both cases.
