Date: Sat, 21 Mar 2009 22:46:56 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-geom@freebsd.org Subject: Re: RFC: adding 'proxy' nodes to provider ports (with patch) Message-ID: <gq3n8u$98n$1@ger.gmane.org> 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
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig489BDBA41EDF048D75E21F0D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Poul-Henning Kamp wrote: > In message <20090321200334.GB3102@garage.freebsd.pl>, Pawel Jakub Dawid= ek write > s: >=20 >> Special GEOM classes. >> --------------------- >> >> - There are no special GEOM classes. >> >> I wonder if phk changed his opinion over time. :) >=20 > 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 th= em * 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. >=20 > I have not had time to read this entire thread, being somewhat > snowed under with work elsewhere. >=20 > First up, I am not sure I understand why the proxy nodes would > be the (or even 'a') right solution for I/O scheduling. >=20 > In fact, it is not very clear to me at all that scheduling should > happen inside geom at all. >=20 > 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 NC= Q. > 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. --------------enig489BDBA41EDF048D75E21F0D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknFYFEACgkQldnAQVacBcigAQCfQWfv8DVzp4TwDYh8QLkidN6U l/YAoNAc/pckuWXX5MLcZT0aDUmHPaJf =lZEp -----END PGP SIGNATURE----- --------------enig489BDBA41EDF048D75E21F0D--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?gq3n8u$98n$1>