GEOM metadata manager (was: Re: [CFC/CFT] large changes in the loader(8) code)

[Andrey V. Elsukov]

On 29.06.2012 3:07, Pawel Jakub Dawidek wrote:
>> [...] If the metadata was somewhere
>> else, then we wouldn't need to kluge various places to deal with the
>> ambiguity and visible interoperability problems of the various tools and
>> OSes. [...]
> 
> Where is "somewhere else", exactly?
> 
> If somewhere else on this disk, then where? At the begining of the disk?
> Then you would complain that it keeps metadata where the primary header
> should be located and also MBR metadata, BSDlabel metadata, etc.
> Somewhere in the middle of the disk? Some future GPTng may want to use
> the same spot, but also gmirror-unaware boot loader will see corrupted
> data (shifted by one sector). Come on...
> 
> If somewhere else is not on this disk, then I'm sorry, but this is
> totally impractical. Disks are the place you store stuff. In 99% of the
> cases there is no other place to store it, but the disk itself. Should
> we ask users to use additional disk to keep mirror's metadata?

I have an idea. A new GEOM class GEOM_MDMGR. It provides new API to write and
read metadata, e.g.: g_read_metadata(...) and g_write_metadata(...) functions.
It keeps own data on the specially delegated for this partition.
+--------------------------------
| GEOM_MDMGR header
+--------------------------------
| GEOM_MDMGR database
|   the list of entries
+--------------------------------
| one sector for each geom
+--------------------------------
| ....
+--------------------------------
| GEOM_MDMGR header
+--------------------------------

Now, we can modify each needed GEOM class and replace some g_write_data/g_read_data
with new functions. How it will work:

When GEOM class tastes some provider it calls g_read_metadata(). GEOM_MDMGR receives
request for reading metadata and looks in the database. It analyzes information
that gets from the parameters list. This may be: geom rank, provider size, block offset, etc.
If there is none registered in the database, then GEOM_MDMGR just forwards this request
to the given provider. If there is some metadata registered, then it returns this metadata to
the geom.

We can keep this database on each device, it can contain information about all geoms,
i.e. not only about device where the database is. It can provide to us new abilities,
like taste ordering based on the rank...

Of course there are some problems that need to ponder.

-- 
WBR, Andrey V. Elsukov


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20120629/a1961635/signature.pgp