From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 06:18:22 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 9EFE416A4CE for ; Fri, 8 Apr 2005 06:18:22 +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 5C88643D2F for ; Fri, 8 Apr 2005 06:18:22 +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 j386IIUi007316; Thu, 7 Apr 2005 23:18:22 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050408055144.GA6147@nagual.pp.ru> References: <21342.1112914675@critter.freebsd.dk> <09c6072206df99be25e345b7e13354f5@xcllnt.net> <20050408050405.GA5203@nagual.pp.ru> <19f3c4e12937f581f7420bc841a11810@xcllnt.net> <20050408055144.GA6147@nagual.pp.ru> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 7 Apr 2005 23:18:17 -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 06:18:22 -0000 On Apr 7, 2005, at 10:51 PM, Andrey Chernov wrote: >> 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. > > It bring some problems like illegal on-disk modification synced to > in-core. Q: what would you consider illegal on-disk modifications? > Since on-disk editing is not controlled (and should not be), it > may overlap or be incorrect in some other way. Q: why is on-disk editing not controlled and why shouldn't it be? > But, if you edit in-core > partition instead, as I suggest, you can do all sorts of checking and > safety, easily excluding overlaps, etc. I can't say I buy into that. I don't see how in-core editing can be better checked than on-disk editing. Can you explain? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net