From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 01:20:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4BD816A4CE; Wed, 12 Nov 2003 01:20:25 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6709143F3F; Wed, 12 Nov 2003 01:20:24 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hAC9KNtB033134; Wed, 12 Nov 2003 10:20:23 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: David Schultz From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 08 Nov 2003 18:30:41 PST." <20031109023041.GA9171@VARK.homeunix.com> Date: Wed, 12 Nov 2003 10:20:23 +0100 Message-ID: <33133.1068628823@critter.freebsd.dk> cc: hackers@FreeBSD.ORG cc: Lukas Ertl Subject: Re: geom_mirror implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 09:20:25 -0000 In message <20031109023041.GA9171@VARK.homeunix.com>, David Schultz writes: >On Sun, Nov 09, 2003, Lukas Ertl wrote: >> Hi hackers@, >> >> I've played around with GEOM a bit and beefed up geom_mirror, which is >> already in the tree but not built yet. >> >> You can find the patch at . > >Hmm...I believe geom_mirror is supposed to be an example, and >geom_ccd is supposed to be the production mirroring implementation. >ccd does have its quirks, though... I guess I should just weigh in here: geom_mirror was meant mostly as a "hands on" example to inspire people writing GEOM classes. It is 100% inside the envelope to improve geom_mirror and provided the patches are sane I see no reason not to commit them. GEOM_CCD has many shortcomings and is only provided for backwards compatibility. It should die, rather than be improved. In general my position is that I would like to get a chance to see any patch committed to the GEOM infrastructure before it's committed (unless it is just trivial matters like typos etc: just go ahead). For individual GEOM classes I'll be happy to review and comment (time permitting) and generally don't care what people do as long as they don't break my system. With regards to the larger "volume management picture" I will reiterate my position: Ideally I would prefer to have a set of primitive GEOM classes, GEOM_MIRROR, GEOM_STRIPE, GEOM_RAID5 etc and a separate set of "controller" GEOM classes, GEOM_VINUM, GEOM_RF, GEOM_VERITAS, to recognize the various "traditional LVM" metadata on the disk, and from that metadata stack the primitive modules. This would in the long term give us the maximal flexibility and ability with the least code. But since I am not going to do that (lack of time), I will not try to impose my will on the people who are doing the work: GEOM is extensible enough for us to have any number of (competing) classes. So realistically I expect that we will some day soon see a GEOM_RAIDFRAME (I gather Pawel is trying to help Scott on this). Maybe we will also see a GEOM_VINUM class and who knows what else. And maybe some day down the road, somebody will pick up on the consolidation idea, or maybe he will instead show it to be hopelessly idealistic and burried it firmly. -- 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.