From owner-freebsd-arch@FreeBSD.ORG Thu Aug 31 12:42:57 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C8C416A4DE for ; Thu, 31 Aug 2006 12:42:57 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29E8A43D77 for ; Thu, 31 Aug 2006 12:42:55 +0000 (GMT) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GIlse-0004rp-1R for freebsd-arch@freebsd.org; Thu, 31 Aug 2006 14:42:48 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Aug 2006 14:42:48 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Aug 2006 14:42:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Thu, 31 Aug 2006 14:42:10 +0200 Lines: 25 Message-ID: References: <20060831121426.GA27060@stud.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en In-Reply-To: <20060831121426.GA27060@stud.ntnu.no> Sender: news Cc: freebsd-current@freebsd.org Subject: Re: Improvements to gvinum and it's future X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2006 12:42:57 -0000 Ulf Lilleengen wrote: > Now, one could ask why I bother doing work on gvinum now, since we have gmirror, > gconcat, graid3 and all that. The reason is that gvinum is important as a volume > manager. Ivan Voras' work on gvirstor seems very promising as a foundation of a > new volume manager, and I've been planning to start working on utilities (fvm, > freebsd volume manager) that utilize these new geom classes instead of having to > maintain a separate RAID implementations, but that will take time, and meanwhile I'm not the one with power-of-decision here, but I think this would be very counter-productive. I'd suggest a different approach, of which I had plans on actually doing, but got sidetracked - to build a userland utility that would use existing GEOM classes in more-or-less opaque way to the user (meaning: users don't have to be aware of actual kernel classes to do the job). The idea was to build a curses terminal interface application (actually, the Original plan was to do it as a part of a new X11 installer that would be able to run standalone) which would allow users to graphically (or at least - visually) draw the graph of classes they want (e.g. RAID 1+0, etc.) and the utility would generate the correct sequence of commands to load and configure the classes, and also write a config file of sorts (or maybe a runnable shell script) that can replicate that configuration, for purpose of repeating in case of disaster or on another machine.