New BSD Installer

Freddie Cash fjwcash at gmail.com
Fri Feb 17 05:37:49 UTC 2012


On Thu, Feb 16, 2012 at 6:40 PM, Warren Block <wblock at wonkity.com> wrote:
> On Thu, 16 Feb 2012, Jeremy Chadwick wrote:
>
>> On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote:
>
>
> (...Linux mdadm)
>
>> So for version 0.90 of their metadata format, you lose drive capacity by
>> about 64-128KBytes, given that the space is needed for metadata.  For
>> version 1.0, I'm not sure.  For version 1.1 it looks like the metadata
>> can be stored at the beginning.
>>
>> So overall, this sounds to me like the equivalent of if GEOM was to
>> "lie" about the actual capacities of the devices when using classes that
>> require use of metadata (gmirror, etc.).
>
> Sorry, I may be misunderstanding your point.  GEOM classes don't lie, they
> accurately represent the space.  The space provided by a gmirror is one
> block less than the actual space occupied, to allow for the metadata block
> at the end.  The problem is that GPT puts backup partition tables at the end
> of the physical (not logical) device. Create a GEOM device on that drive,
> and the GEOM metadata overwrites the backup GPT partition table.  Well, the
> last block of it, anyway.
>
> But create the GEOM device inside a GPT partition that spans the drive, and
> things are fine.  The GPT backup tables are safely outside the GEOM
> metadata, which is safely outside of the data.
>
> Short-form: GPT tables are at the absolute start and end of the physical
> disk.  GEOM metadata is relative, at the end of the logical device, not
> necessarily the end of the physical device.

Seems to me that we need a GEOM-aware loader that can "taste" the GEOM
metadata on a disk *before* the GPT is read, such that the "first and
last physical block of the disk" becomes "the first and last physical
block of the GEOM provider".  Perhaps by storing the GEOM class
metadata in the first and last blocks of the provider.  Then you just
start reading the start of the disk, notice a gmirror metadata block,
setup the gmirror, notice a gstripe metadata block, setup the gstripe,
notice a GPT metadata block, load the GPT partitions, etc

No idea just how feasible this would be, though.

-- 
Freddie Cash
fjwcash at gmail.com


More information about the freebsd-stable mailing list