Sorry for following up to self, but ... I just noticed somebody else suggesting the same method (put GMIRROR configuration below Secondary GPT header), but I think there is a problem: If GMIRROR is used to mirror whole GPT partitioned drives, then you want the GPT sectors to be considered part of the mirror (to keep them identical when GPT partitions are created/modified on the mirrored disks). But the GMIRROR configuration must not be assigned to any GPT partition. Therefore it must be protected, either by hiding it (e.g. create a special partition to hold GEOM config data, just to reserve the space within GPT, since the configuration data will still be located by looking at specific sectors of the provider), or by skipping the sectors assigned to GEOM config data in the GEOM provider that interprets them (e.g. GMIRROR). The former only works if a GMIRROR (or GELI or whatever) is created on a disk that already has GPT headers (since these lead to the GEOM config data put before the Secondary GPT header and allow the GEOM config to be marked as a special partition in that header). The latter only works on disks without GPT headers, since the size of the provider will be smaller then the physical disk. Even with the last physical disks available for GPT, the GPT headers will probably not conform to the standard, since remapping of the sectors to hide the GMIRROR config will lead to different logical sector numbers for the secondary GPT header when looked at with or without GMIRROR loaded. I still think it is possible to find a layout, that does not violate the GPT standard (use last LBAs on disk, have self-referential information like own LBA address consistent with physical block numbers and block numbers presented to users of GMIRROR et.al.). Perhaps, GMIRROR could treat its configuration sector (that is placed at the sector just below the secondary GPT header) as read only. Requests may go to all sectors below and also to the area above the GMIRROR config sector used for the GPT header, to write it to all mirrored devices). But this is also ugly, since GPT must know to not assign the GMIRROR config sector to any partition (it is read- only for user requests, but writable on each individual drive in case of GMIRROR configuration or state changes, just as it is now). The reservation was best achieved by use of a specific GPT partition for the configuration data, for which GPT headers must exist, before the GMIRROR is created (or bith must be created at the same time, but that would mix GPT knowledge into GMIRROR). All of the above is ugly, U'm afraid :( Regards, STefanReceived on Thu Jun 28 2012 - 08:10:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC