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

[Ivan Voras]

Poul-Henning Kamp wrote:
> In message <20090321200334.GB3102 at garage.freebsd.pl>, Pawel Jakub Dawidek write
> s:
> 
>> 	Special GEOM classes.
>> 	---------------------
>>
>> 	- There are no special GEOM classes.
>>
>> I wonder if phk changed his opinion over time. :)
> 
> He didn't.

Well, let's not call them "GEOM classes" then - call them "GEOM proxies"
:) Seriously, *if* there should be things like they are described in
this thread, we should write down what they should do and then decide if
it's worth reusing the "GEOM class" name and infrastructure. My attempt
at this (still under the *if* part) is:

	* They should probably modify bio's in-place, if it's possible, or in
some other way ensure 1:1 mapping of the IO requests that pass through them
	* The following "GEOM class" and "GEOM instance" methods are NOT
needed: destroy_geom, taste, access, dumpconf
	* ... the following ARE needed: ctlreq, start, stop
	* ... the following may be needed: init, fini, orphan, spoiled

(I'm trying to keep them light-weight :) ).

>> 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.
> 
> First up, I am not sure I understand why the proxy nodes would
> be the (or even 'a') right solution for I/O scheduling.
> 
> In fact, it is not very clear to me at all that scheduling should
> happen inside geom at all.
> 
> I would tend to think that it belongs in the devicedriver, where
> intelligent information about things like tagged queuing abilities
> can be taken into account.

Except for "dumb" controllers and/or drivers. AFAIK our ATA doesn't do NCQ.

> For any kind of scheduling to do anything non-trivial, requests
> needs to be piled up so they can be reordered, doing that in
> places where bio's dont naturally pile up would require a damn
> good argument and strong numbers to convince me.
>
> Where the already do pile up, the existing disksort mechanism
> and API can be used.  (If you want to mess with the disksort
> *algorithm*, by all means do so, but that should not require
> you to hack up any apis, apart from the one to select algorithm).

Well, each layer in common Intel servers today does its own scheduling:

* The OS - it's was a big deal when Linux and Vista implemented them
* The (smart) disk controllers
* The drives themselves.

I don't know enough to clam it is good or bad, but there's probably
something in there.

> 2. There still are not, and should not be created any special GEOM
>    classes.  GEOM derives much of it's strength from the fact that
>    there are no special cases to handle, that shouldn't be sold
>    too cheaply.
> 3. Do it properly instead: Implement the general insert/remove
>    properly, so that we can do things like the "move" example above.

Doesn't the inclusion of "hot-swappiness" in the topology tree mean that
either the existing classes need to be modified extensively, or that
there must be some kind of flag telling which classes support this
mechanism and which don't, effectively segregating them?

Also, some classes don't have a meaning in the "proxy" context, like
stripe, concat, raid3, vinum, etc. What I'm trying to say is that it
isn't the classes (in the narrow sense) that have the magical "no
special cases" property, since they are obviously constrained by the
nature of their task, but the framework. Any "GEOM proxy" (if we go that
route...) will obviously be made usable in any place in the topology.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090321/e8b44975/signature.pgp