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

[David Cross]

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.

[Warner Losh]

Why '-geom'? Why not 'freebsd-misc'?

And what, exactly, do you mean by 'create a GPT partition'?

Warner

Post by David Cross
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.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[David Cross]

Because I apparently I suck at mailing lists. Sorry for the dupe messages coming :(

I am not picky about the name; I picked -geom since it seemed to be part of the geom system (yes.. I know 'everything' is part of the geom system in that sense); but geom-labeled? Not sure what else to call it. 'misc' seems overly broad, there's a very specific but common (I think) use case where people have gmirrors, gstripes, geli, gconcat, etc...) they are using

Post by Warner Losh
Why '-geom'? Why not 'freebsd-misc'?
And what, exactly, do you mean by 'create a GPT partition'?
Warner

Post by David Cross
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.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Rodney W. Grimes]

Post by David Cross
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,

[David Cross]

This post might be inappropriate. Click to display it.

[Eugene Grosbein]

Post by 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.

One should just be allowed to mark such a partition "unbootable" so no loader even tries to boot it.
And use any kind of label you like including freebsd-ufs.

We should not "workaround" deficiencies of our loaders (if any) but fix it
instead of invention of new partition types just for that strange reason.

Post by David Cross
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.

Why is it important how BIOS shows gstripe'd partitions if they are marked not bootable?

There were times when BIOSes unconditionally booted from floppy disk drive if it had readable floppy disk
at boot time, so boot area of such floppy disks had special code saying "Non-system disk, replace and strike a key"
if a floppy was not supposed to be bootable. Boot area of our non-bootable partitions might have something similar.

[Warner Losh]

Post by David Cross

Post by 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.
One should just be allowed to mark such a partition "unbootable" so no
loader even tries to boot it.
And use any kind of label you like including freebsd-ufs.

How does one do that?

We should not "workaround" deficiencies of our loaders (if any) but fix it

Post by David Cross
instead of invention of new partition types just for that strange reason.

Normally this is a non issue.

Post by David Cross
If you have a raw raid gstripe, what shows up to the BIOS as to what this drives is depends

Post by David Cross
entirely on the _contents_ of the drive at a specific position,

information that could be controlled by a user.
Why is it important how BIOS shows gstripe'd partitions if they are marked not bootable?
There were times when BIOSes unconditionally booted from floppy disk drive
if it had readable floppy disk
at boot time, so boot area of such floppy disks had special code saying
"Non-system disk, replace and strike a key"
if a floppy was not supposed to be bootable. Boot area of our non-bootable
partitions might have something similar.

No. They don't. There is no standard way to mark something unbootable...

Warner

_______________________________________________

Post by David Cross
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Eugene Grosbein]

Post by Warner Losh
No. They don't. There is no standard way to mark something unbootable...

Then a code in the boot area of our non-bootable partitions should prevent meaningless boot attempts
preferably skipping to next partition or drive like our boot0 can.

[Eugene Grosbein]

Post by Warner Losh

Post by Eugene Grosbein
One should just be allowed to mark such a partition "unbootable" so no
loader even tries to boot it.
And use any kind of label you like including freebsd-ufs.

How does one do that?
We should not "workaround" deficiencies of our loaders (if any) but fix it

Post by Eugene Grosbein
instead of invention of new partition types just for that strange reason.

Normally this is a non issue.

Post by Eugene Grosbein
If you have a raw raid gstripe, what shows up to the BIOS as to what this
drives is depends

Post by David Cross
entirely on the _contents_ of the drive at a specific position,

information that could be controlled by a user.
Why is it important how BIOS shows gstripe'd partitions if they are marked not bootable?
There were times when BIOSes unconditionally booted from floppy disk drive
if it had readable floppy disk
at boot time, so boot area of such floppy disks had special code saying
"Non-system disk, replace and strike a key"
if a floppy was not supposed to be bootable. Boot area of our non-bootable
partitions might have something similar.

No. They don't. There is no standard way to mark something unbootable...

For UEFI case there is the BootOrder list useful for this particular task.