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

[David Cross]

Just a named GPT UUID type, like freebsd-swap, freebsd-ufs

As for ambiguous data: consider you have a RAID 10 of a UFS filesystem.  If you put that into freebsd-ufs freebsd-boot will see that and potentially attempt to boot it.  If you have a raw raid gstripe, what shows up to the BIOS as to what this drives is depends entirely on the _contents_ of the drive at a specific position, information that could be controlled by a user.  So to 'the bios' the meaning is what the OS put there, but the OS put user data there; how does the OS control the intent (as the BIOS sees it) of that data?

On Jul 29, 2018, at 17:02, Rodney W. Grimes <freebsd-rwg at pdx.rh.CN85.dnsmgr.net> wrote:

>> 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