Re: A replacement for GEOM_LABEL's gpt/gptid

From: Andrey V. Elsukov <ae_at_FreeBSD.org>
Date: Thu, 18 Aug 2011 09:58:07 +0400
On 18.08.2011 4:08, Nathan Whitehorn wrote:
>> What it contains:
>> * gpt/gptid support removed from GEOM_LABEL class;
>> * new GEOM_ALIAS class added. This class has two public functions:
>> void g_alias_create(struct g_provider *pp, const char *name);
>> void g_alias_spoil(struct g_provider *pp);
>> * first two consumers of GEOM_ALIAS class are GEOM_PART and GEOM_DISK:
>>
>> GEOM_DISK uses g_alias_create() to create aliases for disks, disk's
>> serial number is used for alias name.
>>
>> GEOM_PART uses g_alias_create() to create aliases for labeled partitions
>> (gpt/gptid, apm and pc98).
>>
>> How it looks like:
>> http://paste.org.ru/?5exeve
>>
>
> What happened to this? It would be really nice to have in 9.0, or soon after anyway. Anything I can
> do to help it along?

:)
Well, there were some problems found.
AFAIR, the last patch i tested is here:
http://people.freebsd.org/~ae/geom_alias.diff

Among other things it slightly extends GEOM core to be able pass trough taste
and spoil events.

To recall for myself how it works:
I added new GEOM class - GEOM_ALIAS. It provides two public functions:

void g_alias_create(struct g_provider *pp, const char *name);
    It creates one instance of geom_alias class for given provider and
    this instance might have several providers (aliases).

void g_alias_spoil(struct g_provider *pp);
    It destroys all aliases for given provider if they are not in use.
    If some alias is used, then function only marks it as stale.

The access method of GEOM_ALIAS class destroys stale provider when it is released.
The spoiled method calls g_spoil() for each alias, i.e. it passes spoil event to
consumers of all aliases.
The taste method checks given provider and if it has GEOM_ALIAS consumer
and it was spoiled before, then it does "retaste" for each alias.

I don't remember what were the results of testing, but looks like there is something
that could be improved.

-- 
WBR, Andrey V. Elsukov
Received on Thu Aug 18 2011 - 04:16:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC