0

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:

  1. Bulldoze online: dd if=/dev/zero bs=512 count=1 of=/dev/sdc and run partprobe and blkid afterwards. But wont that trip up any mdadm or anything else somehow?
  2. fail the member, disconnect (logically), bulldoze first few MiBs off-line, reconnect (logically), re-synchronize. I'd rather not.
  3. 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.

1 Answer 1

0

I believe the issue that you are facing is that data written to a RAID member happens to look like a partition table. The fix is quite simply to ignore the partitions and carry on regardless. There is probably a way to set a "data offset" for all RAID members to avoid this problem.

1
  • I never wrote any data to an individual RAID member after array creation. And the data written to mdX was not a partition table, but an LVM physical volume header. In the created logical volume I put a File-system directly, again no partition table. And the filesystem created was ext4, not NTFS. I think there is no doubt, that the old partition table was present before array creation, and it is now somehow tripping up the kernel and blkid. Commented Nov 26, 2016 at 8:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .