From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 05:34:39 2005 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 7538116A4CE for ; Fri, 8 Apr 2005 05:34:39 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5B1643D58 for ; Fri, 8 Apr 2005 05:34:38 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j385YcZI007117; Thu, 7 Apr 2005 22:34:38 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050408050405.GA5203@nagual.pp.ru> References: <21342.1112914675@critter.freebsd.dk> <09c6072206df99be25e345b7e13354f5@xcllnt.net> <20050408050405.GA5203@nagual.pp.ru> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <19f3c4e12937f581f7420bc841a11810@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 7 Apr 2005 22:34:37 -0700 To: Andrey Chernov X-Mailer: Apple Mail (2.619.2) cc: Poul-Henning Kamp cc: current@FreeBSD.ORG Subject: Re: GEOM architecture and the (lack of) need for foot-shooting 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: Fri, 08 Apr 2005 05:34:39 -0000 On Apr 7, 2005, at 10:04 PM, Andrey Chernov wrote: >> I think that having a single view is probably what's biting. If you > > Yes. But who speak about single view? If we have in-core and on-disk > partition separately, we need _two_ independent views, choosed f.e. by > some option. Your angle is slightly different from mine. We do share that the on-disk and in-core data can differ, but you seem to allow editing of the in-core data by partitioning tools, while I don't. The way I look at it is that the kernel builds the in-core data from the on-disk data when the disk is first discovered. The in-core data is dropped when the disk disappears. The on-disk data can be modified by partitioning tools. The in-core data does not change because of that, but the in-core data can be brought in sync with the on-disk data by some means (sysctl, ioctl or whatever). The in-core data cannot be edited on its own. The idea here is that you remain in control while you make modifications and to allow updating the in-core data in a way that's most suitable for the sysadmin or the tool he/she is using. I think it's important to have that clear. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net