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

[Poul-Henning Kamp]

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.

>[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.

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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.