From owner-freebsd-geom@FreeBSD.ORG Sun Mar 22 08:22:03 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 941531065672; Sun, 22 Mar 2009 08:22:03 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 554AB8FC1A; Sun, 22 Mar 2009 08:22:03 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1F37F3F129; Sun, 22 Mar 2009 08:22:02 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2M8M1d0045753; Sun, 22 Mar 2009 08:22:01 GMT (envelope-from phk@critter.freebsd.dk) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 22 Mar 2009 02:10:46 +0100." Date: Sun, 22 Mar 2009 08:22:01 +0000 Message-ID: <45752.1237710121@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: luigi@freebsd.org, Pawel Jakub Dawidek , Ivan Voras , freebsd-geom@freebsd.org 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: Sun, 22 Mar 2009 08:22:03 -0000 In message , 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.