Hi David, Adam, On 07/26/2016 05:52 AM, Adam Goryachev wrote: > On 26/07/2016 18:20, David C. Rankin wrote: >>>> # cat /proc/mdstat >>> Personalities : [raid1] >>> md4 : active raid1 sdc[0] >>> 2930135488 blocks super 1.2 [2/1] [U_] >>> bitmap: 0/22 pages [0KB], 65536KB chunk > No, I'm saying that is an excellent idea, and it is exactly what I > always do. The problem is that you created the single large primary > partition, and then used the raw drive for the raid array instead of > using the partition. The drive probably came with a single large partition in a GPT table. mdadm was created using the whole disk, which neither needs nor expects there to be a partition table. (I do not use partitions for my big arrays -- whole disks only.) When mdadm created the array, it probably wiped out the starting table, but not the GPT backup. Which may or may not be outside the used data area of the array. So you allowed a partition tool to "fix" a partition table that isn't being used. The simplest solution is to zero the first 4k of the disk and zero the GPT backup partition table location. I suggest re-adding /dev/sdd to the array (not /dev/sdd1, and not --add), whether you delete the table or not. A --re-add will probably be nearly instant, since there is a bitmap. Phil -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
