On 07/26/2016 12:14 PM, Phil Turmel wrote: > 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. Well, no, that was my stupidity in forgetting to add the '1' at the end of sdc/sdd during mdadm --create. So you are saying it would be OK to add sdd back into the array and just use the whole drive, even though there is an empty/unformatted sdd1 (as there was all along) and that the whole-drive array is OK? Will adding it back into the array overwrite the primary PT again, or was that just a result of initial array creation due to the fact I was using the whole drive _and_ sdd1 existed as well. (Well that looks to be the gdisk complaint, the sdd1 table was overwritten, but that didn't effect the array operation because it was using the whole drive. -- so I could have ignored the gdisk warning and gone about my merry way without this day of learning and angst? Ah, but what's the fun in that...?) -- David C. Rankin, J.D.,P.E. -- 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
