Date: Sun, 22 Mar 2009 08:22:01 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: luigi@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Ivan Voras <ivoras@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: RFC: adding 'proxy' nodes to provider ports (with patch) Message-ID: <45752.1237710121@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 22 Mar 2009 02:10:46 %2B0100." <eb21ef440903211810gbe60b9bwee87eb441777aa62@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <eb21ef440903211810gbe60b9bwee87eb441777aa62@mail.gmail.com>, Luigi Rizzo writes: > BEFORE ---> [ pp --> gp ... ] > AFTER ---> [ pp --> new_gp --> new_cp ] ---> [ new_pp --> gp ... ] Correct. There are many reasons for doing it this way, but the two major ones are: 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. 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. 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. >[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. You would not call taste() anyway, because all the new stuff is already open and active. 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. 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45752.1237710121>