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

[Poul-Henning Kamp]

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.

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

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


With that said: I always envisioned the ability to insert and
delete transparant nodes, with the poster boy example being:

	insert a mirror geom
	add a mirror on some other provider
	sync them.
	delete the old mirro copy
	pull 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}  combination 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:

1. Why would you do scheduling in the middle of the GEOM mesh ??
   Very strong arguments and numbers will have to be forwarded
   for that to be a reason to deviate from:

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.

Poul-Henning

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