From owner-freebsd-current@FreeBSD.ORG Mon Jan 12 01:13:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 719F016A4CE; Mon, 12 Jan 2004 01:13:32 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C854243D45; Mon, 12 Jan 2004 01:13:29 -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 i0C9DROl033571; Mon, 12 Jan 2004 10:13:27 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "Greg 'groggy' Lehey" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 Jan 2004 15:46:49 +1030." <20040111051649.GK7617@wantadilla.lemis.com> Date: Mon, 12 Jan 2004 10:13:27 +0100 Message-ID: <33570.1073898807@critter.freebsd.dk> cc: hackers@FreeBSD.org cc: Scott Long cc: current@FreeBSD.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 09:13:32 -0000 In message <20040111051649.GK7617@wantadilla.lemis.com>, "Greg 'groggy' Lehey" >> As much as I would hate to see RF and Vinum disappar from our >> source tree, maybe what we need to do is to kick them both into >> "training-camp" in p4 while you and Greg look the other way. > >Hmm. I can't see why they have to disappear from the source tree, [...] I forgot to mention on rather important factor in this equation: If nothing happens, vinum is going to break even more very soon. The plan for the cleanup of the buffer cache, such as we drew it up at BSDcon, says that filesystems will go directly to GEOM for disk service rather than detour through the vnode layer, SPECFS and then to GEOM. (This is not a matter of our choice of bike-shed color, this is a matter of SMP performance, locking sanity and buf/VM performance.) The first step of this has actually happened with the swap_pager which now goes directly to GEOM, and that is why you cannot put your swapspace on a vinum volume any more. The next target is UFS. The softupdates and snapshot support, because of the way the buffer cache interacts with SPECFS, has callback hooks in SPECFS which do not belong there. The next step is to move UFS to go directly to GEOM and at the same time pull the callbacks out of SPECFS and into UFS (FFS really) where they belong. Once I proceed with that step, you cannot mount UFS on a vinum volume. After that, the rest of the filesystems will follow, one by one. The question in my mind is: What if vinum is not fixed by then ? If it is decided to leave vinum in the CVS tree at this point in time, do we all agree and accept that if not fixed by then, vinum gets disconnected from the build when we proceed with the buffer cache cleanup ? To give an idea about the relative urgency, we are probably talking february or march this year. Poul-Henning -- 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.