Request for comments, new geom part type alias: freebsd-geom

[Rodney W. Grimes]

> I'd like to propose that we create a GPT partition for geom labeled
> partitions (gmirror, gstripe, geli, etc.. anything that can be 'tasted' and
> automatically determined.) called 'freebsd-geom'.
> 
> There are numerous cases where you shouldn't have a raw geom on a disk (for
> example, imagine a raid 10 of a filesystem with VMs on it..on a raw disk
> its possible that the lead block happens to line up with a VM disk image or
> anything else a BIOS may determine is bootable).
> 
> So the question becomes which part id to use; IF its a mirror of a swap of
> UFS it seems perfectly reasonable to use freebsd-swap or freebsd-ufs (if a
> bit dangerous).  If its a mirror or a geli then you can again be in the
> situation where the boot blocks (or something else), in certain
> circumstances mistakes these for raw filesystems with similarly calamitous
> results.
> 
> Given these, it seems a 'freebsd-geom' (or similar) seems entirely
> appropriate; we can mark these for what they really are, and eliminate
> these cases where the system misinterprets intentions based on ambiguous
> data.

Do you have more details on just how your going to implement a "GPT"
partition for geom labeled partitions.  Though I think I understand
what it is you want to do, how you describe it leads to some confusion
on just what you are desiring to do.

I am aware of some major issues involving gmultipath (GEOM::MULTIPATH)
and gpt partitioned disks (GEOM::GPT) that due to bad tasting priorities
you get bogus GPT error messages during boot if you have labeled your
gmultipath devices, and infact can damage a gpt disk if you apply a
multipath label onto a valid gpt disk.  

Please describe the "ambiguous data" as well, as I am not aware of
what that would be.

Thanks,
-- 
Rod Grimes                                                 rgrimes at freebsd.org