On Sep 23, 2012, at 11:44 AM, Chris Murphy wrote: > > If IMSM only applies an offset to the end of the disk, such that it merely changes the last usable LBA and therefore there is a 1:1 correlation between array LBA's and physical disk LBA's, the kernel would find the alternate GPT header. Yet it isn't, so still something isn't right. 1. IMSM metadata starts at LBA -32 from the end of the physical disk after issuing this command: mdadm -C /dev/md/imsm /dev/sd[bc] -n 2 -e imsm At this point nothing else is on the disk, per hexdump. 2. A small amount of additional data is added in those reserve 32 sectors at the end of the physical disk after issuing this command: mdadm -C /dev/md/vol0 /dev/md/imsm -n 2 -l 1 3. gdisk sees /dev/sdb as having 16777216 sectors. gdisk sees /dev/md/vol0 has having 16769024 sectors. 4. Upon creating a GPT on /dev/md/vol0, identical structures at identical byte offsets are created on /dev/sd[bc] and /dev/md/vol0. The primary GPT header says the alternate header is at 0xffdfff. The alternate GPT header is at 0xffdfff., or sector 16769023, right where it should be. Regardless of whether the kernel sees the disk as Intel RAID or a bare disk, it finds the alternate GPT header, and doesn't complain about anything. Conclusions: A. There is a 1:1 correlation between physical disk LBA and array LBA (at least for RAID 1), there is merely an offset at the end of the disk for IMSM metadata. B. Günther's disks had GPTs made on the physical disk devices themselves, prior to the creation of IMSM metadata. When IMSM metadata was created, the alternate GPT header and table data were squished because it was in the wrong location. C. The fact Günther's "mdadm -E" command on the physical disks reveals both are in a dirty state, indicates to me the array is not assembled, and is not presently mirroring. So I think he's actually not booted from or using the array at all, at least not from within linux. Chris Murphy-- 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
