Re: GPT Table broken on a Raid1

On 22/09/2012 19:45, Chris Murphy wrote:

On Sep 22, 2012, at 9:31 AM, John Robinson wrote:

quoted

I don't think there's anything wrong here.

The kernel sees the whole discs, sda and sdb, and complains that the GPT partition table looks wrong becase the second copy isn't at the end of the discs. That's correct, at the end of the raw discs is the IMSM metadata.

OK so sda and sdb shouldn't have been partitioned in the first place, is what that tells me.

That's not what I'm saying. I'm saying that sda and sdb weren't 
partitioned in the first place. I'm saying that when the Linux kernel 
boots, and the AHCI driver starts, it sees the IMSM member discs as raw 
discs, which get probed for partitions. The GPT partition probe spots 
one of the copies of the GPT partition, but can't find the other one 
because the IMSM metadata's there. Then later on, md starts, reads the 
IMSM metadata, and presents the RAID set, including the GPT partition 
table that the raw-disc probe already whinged about, but which in the 
RAID set is correct.

The error messages that Günther saw are a false positive and harmless - 
or at least, harmless until someone starts telling him to go messing 
around rewriting the contents of the raw drives underneath md by 
deleting the misidentified partition tables, the effect of which is 
likely to be to damage his partitions inside the IMSM array and/or 
destroy the IMSM array metadata.

quoted

Don't try to change the partition tables on /dev/sda and sdb or you will damage the IMSM metadata.

Sounds like either imsm metadata is either not well designed for GPT

I think I'd describe it was being designed so that individual discs from 
RAID-1 mirrors can be read independently.

IMSM predates GPT anyway.

or it was intended to be placed on an unpartitioned disk in the first place.

It can't be anything else.

Cheers,

John.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html