Re: RFC: Project geom-events

Lev Serebryakov wrote:
> Hello, Miroslav.
> You wrote 5 октября 2011 г., 12:24:06:
>
>>>     What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid?
>>> Something else?
>> I am mostly using geom_mirror.
>    [SKIPPED]
>    Oh, I see. Unfortunately, there is no GEOM metadata infrastructure,
> GEOMs are too generic for this. I could design some meta-meta
> framework, and unify all RAID classes with "intenral" metadtata
> (geom_stripe, geom_concat, geom_mirror, geom_raid3 and my external
> geom_raid5) to use it. In such case it will work -- kernel will not
> pass providers with "dirty" metadtata to any GEOMs, but owners, for
> tasting. Of course, classes like geom_part and geom_raid could not be
> changed in such way -- they are forced to use pre-defined metadata
> formats.
>
>    It is good idea, but it should be separate project. And, yes, it
>   will change metadata format for these GEOMs, so it will not be
>   backward-compatible.
>
>    And, yes, it seems to be much more intrusive change in GEOM
> subsystem (because it will change tasting sequence), and should be
> supervised by other developers from very beginning.
>
>    I could write proposal in near future, with some design notes.

I am waiting years for the moment, when these GEOM problems will be 
fixed, so I am really glad to see your interest!
It will be move to right direction even if changes will not be backward 
compatible.
The current state is too fragile to be used in production. Gmirror alone 
can be used, glabel alone can be used, GPT alone can be used... but mix 
it all stacked together is way to hell.

e.g. Using GPT on glabeled provider always ends with error message about 
corrupted secondary GPT table. (But how can I use iSCSI in reliable way 
if I cannot use glable on devices and iSCSI device can have different 
number on each reboot? I wrote about it almost 2 years ago)

GEOM layering possibilities are really amazing, but metadata, tasting 
and robustness in edge cases is not well done.

If you are able to come with some fixes in GEOM metadata implementation 
/ handling, I see better future :)
Unfortunately, I am not a C programmer, so I cannot write patches, but I 
can test whatever you will need in this area.

You are right, it should be separate project. I am looking forward to 
your proposal / wiki page.

Thank you again for your work on GEOM improvements!

Miroslav Lachman