On 22/09/2012 19:45, Chris Murphy wrote:
On Sep 22, 2012, at 9:31 AM, John Robinson wrote:
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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
