Date: Sun, 22 Mar 2009 02:10:46 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: luigi@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Ivan Voras <ivoras@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: RFC: adding 'proxy' nodes to provider ports (with patch) Message-ID: <eb21ef440903211810gbe60b9bwee87eb441777aa62@mail.gmail.com> In-Reply-To: <42965.1237667050@critter.freebsd.dk> References: <20090321200334.GB3102@garage.freebsd.pl> <42965.1237667050@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 21, 2009 at 9:24 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wro=
te:
> In message <20090321200334.GB3102@garage.freebsd.pl>, Pawel Jakub Dawidek=
write
> s:
>
>> =A0 =A0 =A0 Special GEOM classes.
>> =A0 =A0 =A0 ---------------------
>>
>> =A0 =A0 =A0 - There are no special GEOM classes.
>>
>>I wonder if phk changed his opinion over time. :)
>
> He didn't.
>
>>Maybe instead of adding special providers and GEOM classes, the
>>infrastructure should be extended in some way, so that we won't use
>>provider term to describe something that isn't really a regular GEOM
>>provider.
>
> I have not had time to read this entire thread, being somewhat
> snowed under with work elsewhere.
...
> With that said: I always envisioned the ability to insert and
> delete transparant nodes, with the poster boy example being:
>
> =A0 =A0 =A0 =A0insert a mirror geom
> =A0 =A0 =A0 =A0add a mirror on some other provider
> =A0 =A0 =A0 =A0sync them.
> =A0 =A0 =A0 =A0delete the old mirro copy
> =A0 =A0 =A0 =A0pull the mirror mirror geom out again
>
> and (tada!) you have migrated a live partition from one disk to
> another.
>
> For that to work, the new class has to end up between the
> consumer(s) and the geom-class, and I generally planned to
> stick a {geom-consumer-provider} =A0combination in between
> the provider and its class, rather than a {provider-geom-consumer}
> between the consumer and its provider.
>
> The reason for this, is that it can be done without stalling
> the I/O stream since bios all have built in return tickets.
>
> So I think, my opinion on this proposal is:
>
...
>
> 2. There still are not, and should not be created any special GEOM
> =A0 classes. =A0GEOM derives much of it's strength from the fact that
> =A0 there are no special cases to handle, that shouldn't be sold
> =A0 too cheaply.
>
> 3. Do it properly instead: Implement the general insert/remove
> =A0 properly, so that we can do things like the "move" example above.
>
> Poul-Henning
>
> --
> Poul-Henning Kamp =A0 =A0 =A0 | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG =A0 =A0 =A0 =A0 | TCP/IP since RFC 956
> FreeBSD committer =A0 =A0 =A0 | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetenc=
e.
>
With the scheduling issues hopefully addressed in the other email/thread:
the only thing we asked in this thread is whether a transparent
insert/remove in GEOM is already possible, or it must be implemented.
It looks like we are in the latter case, so one option we suggested
(and implemented) was to stick "something" between the provider
and its class, with this "something" being a regular geom class.
http://info.iet.unipi.it/~luigi/FreeBSD/20090319-geom-proxy.patch
This seems to be almost (see [1]) perfectly in line with your
suggestion above, does not cause deviations from the model, and
does not introducte special classes (see [2]).
The only thing we need is adding two pointers to decouple the
provider from its geom. I'd love to know if a better way exists,
maybe the behaviour described in note [1] below is what you had in
mind ?
[1]: The way i can read your sententence
... stick a {geom-consumer-provider} combination in between
the provider and its class,
is the following: take the existing provider "pp" attached to geom "gp"
and make it the provider of the new geom "new_gp".
Then create a new provider, "new_pp", link it to "gp",
and link the consumer of "new_gp" to "new_pp". So we have the following=
:
(each node is in square brackets):
BEFORE ---> [ pp --> gp ... ]
AFTER ---> [ pp --> new_gp --> new_cp ] ---> [ new_pp --> gp ... =
]
On removal, relink "pp" to "gp" and destroy all the new_* stuff.
This should save the extra pointers in the struct g_provider,
and perhaps not much harder to implement than what we did ?
[2] the GEOM_PROXY flag that we suggested is just an optimization to
avoid calling taste() on a provider that nobody should be interested
in attaching to. I think its presence does not change the model,
but nothing bad happens if we don't use this flag.
How does it sound now ?
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eb21ef440903211810gbe60b9bwee87eb441777aa62>