RFC: adding 'proxy' nodes to provider ports (with patch)

[Pawel Jakub Dawidek]

On Sun, Mar 22, 2009 at 08:22:01AM +0000, Poul-Henning Kamp wrote:
> In message <eb21ef440903211810gbe60b9bwee87eb441777aa62 at mail.gmail.com>, Luigi 
> Rizzo writes:
> 
> >        BEFORE  ---> [ pp --> gp ...   ]
> >        AFTER   ---> [ pp --> new_gp --> new_cp ] ---> [ new_pp --> gp ... ]
> 
> Correct.
> 
> There are many reasons for doing it this way, but the two major ones
> are:
> 
> Providers see essentially one-way traffic (going down), because the
> bio's have their return-path recorded (admittedly: for this very
> reason), whereas consumers see two way traffic.
> 
> If you wanted to substitute another provider, you would have to stall
> I/O activity on the consumers in order to get all the pointers set
> up right to not derail any bios while doing so.
> 
> If instead you insert under the provider, you can hold topology,
> fiddle the pointers in the right order, and release topology
> all while bios zip up and down over the construction site.

There is still a naming problem. pp and new_pp will end up with the same
name. I'd suggest instructing GEOM to expose only parent in /dev/.

> >[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.
> 
> You would not call taste() anyway, because all the new stuff is
> already open and active.

The taste is still going to be send on new class arrival and on the last
pp write close.

> But you need to add a new g_ctl verb to instantiate a transparant
> instance of the class, and this is where you can tell if inserting
> a given glass is even possible: classes that cannot will error out.
> 
> Similarly, you need a verb to remove a transparent geom, which
> will fail if the class doesn't understand this, or do not consider
> that geom to be transparant.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090323/da9b4b48/attachment.pgp