From owner-freebsd-geom@FreeBSD.ORG Sat Mar 21 21:47:26 2009 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F361F106566B for ; Sat, 21 Mar 2009 21:47:25 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3C08FC08 for ; Sat, 21 Mar 2009 21:47:25 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ll92H-000853-RM for freebsd-geom@freebsd.org; Sat, 21 Mar 2009 21:47:21 +0000 Received: from 93-141-99-248.adsl.net.t-com.hr ([93.141.99.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Mar 2009 21:47:21 +0000 Received: from ivoras by 93-141-99-248.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Mar 2009 21:47:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Sat, 21 Mar 2009 22:46:56 +0100 Lines: 112 Message-ID: References: <20090321200334.GB3102@garage.freebsd.pl> <42965.1237667050@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig489BDBA41EDF048D75E21F0D" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-99-248.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <42965.1237667050@critter.freebsd.dk> X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: RFC: adding 'proxy' nodes to provider ports (with patch) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 21:47:26 -0000 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--