From owner-freebsd-geom@FreeBSD.ORG Sun Mar 22 01:16:45 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 22F991065676 for ; Sun, 22 Mar 2009 01:16:45 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5908FC26 for ; Sun, 22 Mar 2009 01:16:43 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by ewy19 with SMTP id 19so1017671ewy.43 for ; Sat, 21 Mar 2009 18:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=rW4K9XL/+gOKcYQTmqG+qLWLjyqViIcFS5zbTqwgauE=; b=ViqYzDmKMuGsa/4gNylPLyNoPsUy2Lf06e+7/2qvVth+9vu5TCo1LmOXNZQo8BAgOP qZy0HhFezc9Xs91FiW4DIf00KhjyB+SSH9x8q6n/xWl4pIzj4qPTaQYWgBiBV5UQn+rW STYNx9s7z6bdnVAddVtqSwZ+7N4jh4ThoE0/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EdM3GV2Lo3PfgYMD17CqxYLyxvwmDh30x9nU/nyG7ShIBePK6YvdWnhVTI2GbJNXUx ROo88PsweO/w+OkpuBpv8HQ+R2QS0j4YP7PdVbdIViQY4UQRVDO+DweRfAXtuSzjvybl 79jtQlrrmG7s7W7DCABNdyr5QwAkK1VgsTDIw= MIME-Version: 1.0 Sender: rizzo.unipi@gmail.com Received: by 10.210.57.12 with SMTP id f12mr4176008eba.22.1237684246139; Sat, 21 Mar 2009 18:10:46 -0700 (PDT) In-Reply-To: <42965.1237667050@critter.freebsd.dk> References: <20090321200334.GB3102@garage.freebsd.pl> <42965.1237667050@critter.freebsd.dk> Date: Sun, 22 Mar 2009 02:10:46 +0100 X-Google-Sender-Auth: 51416657876adaf2 Message-ID: From: Luigi Rizzo To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 01:16:45 -0000 On Sat, Mar 21, 2009 at 9:24 PM, Poul-Henning Kamp wro= te: > In message <20090321200334.GB3102@garage.freebsd.pl>, Pawel Jakub Dawidek= write > s: > >> =A0 =A0 =A0 Special GEOM classes. >> =A0 =A0 =A0 --------------------- >> >> =A0 =A0 =A0 - There are no special GEOM classes. >> >>I wonder if phk changed his opinion over time. :) > > He didn't. > >>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. > > I have not had time to read this entire thread, being somewhat > snowed under with work elsewhere. ... > With that said: I always envisioned the ability to insert and > delete transparant nodes, with the poster boy example being: > > =A0 =A0 =A0 =A0insert a mirror geom > =A0 =A0 =A0 =A0add a mirror on some other provider > =A0 =A0 =A0 =A0sync them. > =A0 =A0 =A0 =A0delete the old mirro copy > =A0 =A0 =A0 =A0pull the mirror mirror geom out again > > and (tada!) you have migrated a live partition from one disk to > another. > > For that to work, the new class has to end up between the > consumer(s) and the geom-class, and I generally planned to > stick a {geom-consumer-provider} =A0combination in between > the provider and its class, rather than a {provider-geom-consumer} > between the consumer and its provider. > > The reason for this, is that it can be done without stalling > the I/O stream since bios all have built in return tickets. > > So I think, my opinion on this proposal is: > ... > > 2. There still are not, and should not be created any special GEOM > =A0 classes. =A0GEOM derives much of it's strength from the fact that > =A0 there are no special cases to handle, that shouldn't be sold > =A0 too cheaply. > > 3. Do it properly instead: Implement the general insert/remove > =A0 properly, so that we can do things like the "move" example above. > > Poul-Henning > > -- > Poul-Henning Kamp =A0 =A0 =A0 | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG =A0 =A0 =A0 =A0 | TCP/IP since RFC 956 > FreeBSD committer =A0 =A0 =A0 | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. > With the scheduling issues hopefully addressed in the other email/thread: the only thing we asked in this thread is whether a transparent insert/remove in GEOM is already possible, or it must be implemented. It looks like we are in the latter case, so one option we suggested (and implemented) was to stick "something" between the provider and its class, with this "something" being a regular geom class. http://info.iet.unipi.it/~luigi/FreeBSD/20090319-geom-proxy.patch This seems to be almost (see [1]) perfectly in line with your suggestion above, does not cause deviations from the model, and does not introducte special classes (see [2]). The only thing we need is adding two pointers to decouple the provider from its geom. I'd love to know if a better way exists, maybe the behaviour described in note [1] below is what you had in mind ? [1]: The way i can read your sententence ... stick a {geom-consumer-provider} combination in between the provider and its class, is the following: take the existing provider "pp" attached to geom "gp" and make it the provider of the new geom "new_gp". Then create a new provider, "new_pp", link it to "gp", and link the consumer of "new_gp" to "new_pp". So we have the following= : (each node is in square brackets): BEFORE ---> [ pp --> gp ... ] AFTER ---> [ pp --> new_gp --> new_cp ] ---> [ new_pp --> gp ... = ] On removal, relink "pp" to "gp" and destroy all the new_* stuff. This should save the extra pointers in the struct g_provider, and perhaps not much harder to implement than what we did ? [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. How does it sound now ? cheers luigi