Date: Mon, 23 Mar 2009 07:03:25 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: luigi@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it>, Ivan Voras <ivoras@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: RFC: adding 'proxy' nodes to provider ports (with patch) Message-ID: <20090323060325.GN3102@garage.freebsd.pl> In-Reply-To: <45752.1237710121@critter.freebsd.dk> References: <eb21ef440903211810gbe60b9bwee87eb441777aa62@mail.gmail.com> <45752.1237710121@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--2feizKym29CxAecD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 22, 2009 at 08:22:01AM +0000, Poul-Henning Kamp wrote: > In message <eb21ef440903211810gbe60b9bwee87eb441777aa62@mail.gmail.com>, = Luigi=20 > Rizzo writes: >=20 > > BEFORE ---> [ pp --> gp ... ] > > AFTER ---> [ pp --> new_gp --> new_cp ] ---> [ new_pp --> gp .= .. ] >=20 > Correct. >=20 > There are many reasons for doing it this way, but the two major ones > are: >=20 > 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. >=20 > 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. >=20 > 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. There is still a naming problem. pp and new_pp will end up with the same name. I'd suggest instructing GEOM to expose only parent in /dev/. > >[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. >=20 > You would not call taste() anyway, because all the new stuff is > already open and active. The taste is still going to be send on new class arrival and on the last pp write close. > 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. >=20 > 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. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --2feizKym29CxAecD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJxyYtForvXbEpPzQRAkWPAKCP61CZ5//Il3peY/pD9Om4aD8Y/wCfYCKS zy6rU8Ev+ifBrLcPwgE5EPA= =jen3 -----END PGP SIGNATURE----- --2feizKym29CxAecD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090323060325.GN3102>