This issue has been nagging at me for some time.
So I have been reading about GEOM
design and
Classes.
GEOM Classes are broadly used to stack software modules between storage hardware managed by the kernel ("disks") and what is presented to "user" space.
So a simple example would be to start with two physical disks. These may be presented as a mirror using the GEOM MIRROR class. The flexibility of the concept is demonstrated by the ability to encrypt the mirror simply by inserting a GEOM ELI Class (
geli(8)) into the stack.
So the physical disk driver is a "provider". Within the GEOM Class stack, the module above it is "consumer" to module below, and a "provider" to the module above, ad nauseam.
There's a lot (but not all) of the GEOM Classes enumerated in
GEOM(4). Well known ones include disks, partitions, memory disks, concats, stripes, geli, mirrors, multipaths, ZFS VDEVS, labels, ...
GEOMs are both extensible (anyone, following the rules, can write a new one), and topologically agnostic (can be stacked arbitrarily). They are an exceptionally flexible and powerful design feature of FreeBSD.
Each GEOM Class requires a kernel module to be loaded to implement the Class.
For each GEOM Class, the metadata of the Class are located in the last sector of the provider (and thus must fit in it). Not all GEOM Classes require permanent metadata, but most do.
Since GEOMs can be stacked, it follows that, as we traverse the GEOM stack upwards from the kernel,
successive providers will each (usually)
consume the last sector of the previous provider for storing metadata.
Since GEOMs can be stacked arbitrarily, it follows that we can't possibly know how many "last" sectors will be consumed by an unknown (and possibly significant) number of providers. But we must assume that each provider may consume one more sector, and thus the sector count presented will generally drop by one with each step up the GEOM Class stack.
Is it OK to retrofit a "automatic" (permanent)
glabel(8) to a "disk" (provider) already in use by a file system? We know that GEOM LABEL Class will want to use the last sector of the provider for storage of metadata. But this space is in the possession of the file system.
What if we also decide to encrypt the file system using the GEOM ELI Class? Now we need ANOTHER last sector!
My guess is that a GEOM consumer is entitled to use all the sectors offered by the provider, simply because it can not guess how many extra providers may be added to the Class stack at some time in the future. That would prevent the retrofitting extra classes into an existing Class stack (because the last sector is owned by the consumer, and not a new provider).
If my guess is right, the stack of GEOM modules can't, in general, be changed after they are initially established, because the metadata would be trashed. However, there are exceptions since some Classes don't necessarily keep metadata (the "manual"
glabel(8) is an example).
I suspect that if I wrote a file system, I might not use the last sector for a number of reasons... leaving room for the GEOM metadata for a retrospective disk label being one of them.
So I still don't have an answer to the question above... But I do at least know why I would be acutely reluctant to do it.
